Potential carriage return displaying in assembled document

[JessicaFrank]

Template with an address field on one line. User enters address in GI in field type, text long, and adds returns after each line like:
1 Main Street
Lexington, KY 12345
Address line 3 test

In assembled doc, it looks like a carriage return is printing over the "L" in Lexington and "A" in Address. Also looks like a question mark potentially. It's not clear because it overlays the other letters.

Interview at question -
Petition for Domestic Violence Protection 9-1-2022 (3).zip

Issue seen in the 1st template with variable [Location for Coming Near 1 TE]

Answer file with that variable holding a value. (zipped b/c Github doesn't allow .anx uploads)
answer - 2022-09-30T121949.410.zip

Possible solution is to warn user to not enter the address with hard returns, but that won't guarantee no errors like this on assembled document. Ideally A2J Author would not display those hard returns and would instead return them as spaces?

[tobiasnteireho]

not seeing this when assembling with above anx on a2jauthor.org with MacOS Monterey on Firefox 104.0.2. Font issue?

petition-for-domestic-violence-protection-9-1-2022-test-assemble.pdf

[tobiasnteireho]

@JessicaFrank where are you observing this and on what kind of setup (OS, browser, etc)

[JessicaFrank]

Unsure of original report set up, but I observed it on production a2jauthor.org - Windows 10 Pro, Chrome Version 105.0.5195.127

[tobiasnteireho]

@JessicaFrank can you please post the pdf generated?

[JessicaFrank]

d3f12778-204f-4444-b943-da6cb68a1004.pdf
@tobiasnteireho

[tobiasnteireho]

looks like an os font issue as it is fine on my Mac. Do the question mark boxes render for you in the pdf I attached in the comment above?

[tobiasnteireho]

@JessicaFrank do you see the issue in the attached pdf and does the attached answer file generate no boxes?
[petition-for-domestic-violence-protection-9-1-2022-test-assemble-crlf.pdf](https://github.com/CCALI/a2jdat/files/9687796/petition-for-domestic-violence-prot
answer - 2022-09-30T121949.410-crlf.anx.zip
ection-9-1-2022-test-assemble-crlf.pdf)

[tobiasnteireho]

replaced \n with \r\n if works may need to add a filter before rendering pdf

[JessicaFrank]

@tobiasnteireho still see the issue using the answer file you shared above.

and in the PDF

[tobiasnteireho]

Well that's odd. Not appearing in Windows Server 2016 and looks fine.

[tobiasnteireho]

actually the pdf linked here (#125 (comment)) looks fine in Server 2016 also so this might be limited to non server windows

[tobiasnteireho]

reproduced in preview, chrome, and foxit reader on mac and windows. PDF spec does not support printing newlines these need to be stripped or converted to breaks https://stackoverflow.com/questions/51090307/pdf-showing-wrong-character-instead-of-line-feed . In spec is treated as EOL https://ghostscript.com/~robin/pdf_reference17.pdf. Firefox is apparrent outlier that may not quite follow spec.

[tobiasnteireho]

I think the best solution in the meantime is for the address to not be collected in one field and to use multiple single line fileds. This will prevent newlines from being able to be entered at all. The multiple fields can then be concatenated to be displayed on one line.

[JessicaFrank]

The issue for this particular template is that if the author collects in multiple fields and concatenates them on the single line, there's the potential for part of the address to be cut off (ex. If street name runs longer than the allotted space on the line for that field, it'll be cut off.) They could put a character count on a single field for the entire line. They could also leave as is and ask their users not to put line breaks in. I'll talk to the author and give them all the suggestions.