Hi Vircos, thanks for your reply
Vircos wrote:
A second option would be using the <pre></pre> tags. Apply the first the line of the first option and put the content of the field between <pre></pre>. The result would be that flat text (ASCII) will be rendered by the browser as it would be rendered by a normal text-editor. I am not sure if this option works, but you could give it try.
Interestingly enough, this works very well! It even presents the text correctly on the PDF... almost. For some reason, the table rows don't quite expand far enough, and cut off half of the bottom line of text. The font defaults to Courier, but I'll try changing it, and add some padding, in the CSS and see what happens.
Thanks for your help!
Simon
:EDIT:
I've just realised that this solution will only work for one particular table. I have another table where the user can update table entries directly on the screen. Clicking a "save" button will update the table. Because these fields must be editable, I cannot inject HTML into them. By their nature, these fields appear correctly on the screen, but on the PDF the line breaks are not rendered. I have tried manually typing the ASCII \n\r notation, but the PDF literally prints "\n\r" instead of rendering it as a line break.
I find it strange that text areas are happily rendered correctly on the PDF, but text area columns in tables are not. Is this a bug in Ebase?
:EDIT PART II:
I've just noticed that Ebase does in fact render the carriage returns entered into a text area column on a table... However, it puts all the carriage returns at the END of the text, rather than in the correct position. For example if I entered the following text into a text area field on a table:
It appears as follows in the PDF:
Again this only happens on
text areas presented in tables. Text area fields that are added to a form as normal appear correctly on the PDF.