Text sequence has strange effect in Carya PDF toolkit.

[beuvink]

Something strange is going on when adding specific sequences to pdf using PDF toolkit. The text isn't printed and an empty page is added instead.

When attaching the text sequence "0123456789ABC={0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x00,0x00" All is fine.

When attaching the text sequence "0123456789ABCD={0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x00,0x00". This doesn't print and adds a white page.

Update, the text squence "0123456789ABCD=************************************************************************" has the same strange effect.

The sequences here are examples, it also happens with other instances. These are as 'clean' as I could reproduce. It seems like this conflicts with some control code or such.

Q1) Anyone knows what sequence issues are triggering this?

Q2) Anyone knows how to work around actually have this text in the pdf?

See attached example vi to reproduce

[wiebe@CARYA · Accepted solution]

The toolkit tries to fit the string as one peace of text. It will truncate on spaces, but your string doesn't seem to have any.

The result is that the text won't fit a line, so it creates a new page. It won't fit there either, so it gives up.

If you use ", " instead of ",", hopefully it will work better.

If that's not acceptable, you'd have to process the text before using the attach function. There are several ways to do this.

[beuvink]

Thanks.

I can use the 'Fit?' output and then use some more sophisticated approach to break the string.

This will cause some issues as I my intention in this case is to dump some programming code that can't be truncated at will...

But I can imaginge this is a limitation of PDF?

At least when I make a pdf with a very long string using another tool (libreOffice writer) then copy&paste the resulting pdf text has CR/LF inserted as well. In that case.. so be it...:)

[billko]

Myabe you could import pictures of code into the document.  Everyone on these forums thinks that's enough for people to understand their code.😂🤣

[wiebe@CARYA]

---

@beuvink wrote:

Thanks.

I can use the 'Fit?' output and then use some more sophisticated approach to break the string.

This will cause some issues as I my intention in this case is to dump some programming code that can't be truncated at will...

But I can imaginge this is a limitation of PDF?

At least when I make a pdf with a very long string using another tool (libreOffice writer) then copy&paste the resulting pdf text has CR/LF inserted as well. In that case.. so be it...:)

---

No, it's not a limit at all.

That is, the toolkit doesn't truncate except on spaces, because usually you don't want to truncate except on spaces.

The attach functions deals with this by not attaching the text, but if you prefer the text to run off the page, that is possible.

You could make the font smaller, make the page margins smaller or go landscape.

You can attach whitespace, and use insert free text or insert text. The text might run off the page though...

Get Formatted Text can be used to truncate on characters.

Perhaps you can share how you'd like the text to appear in the PDF?

[beuvink]

As a matter of fact.. I am making a text interpreter in LabView...

There aren't enough text languages in the world yet.. thought I would add another one 😉

[beuvink]

"The text might run off the page though..."

That was my thought indeed... and there is a limit on text size. But I'll manage.

If 'Fit?' is false, which will not be often the case I can use the 'calculate bounding box' to see what still fits.

Then I can either just insert a 'CR/LF' where needed and have the user fix this.

Or as my scripting tool I am making is intended as a 'C-like' language, mainly meant to have documented pseudo code for C-programmers in a PDF document I can see if I can extend the interpreter with '\' line endings.

Thinking of it.. as it is code, I can also just calculate max characters on a line as it is all monospace text anyway...

[wiebe@CARYA]

that might have crossed my edits...