The GeoTextCOMPs layoutText method is ognoring newLine. When feeding it a textDAT with multiline content, linebreaks will be handled as if they are one word, instead of a \n textLineObject being passed.
When trying to break down the elements in to single words this is now not easily possible as I cannot catch lineBreaks while looking for characters indicating that.,
Hi @alphamoonbase,
hm, interesting as the result is dealing with glyphs and whitespace characters are probably not considered glyphs.
Checking with @robmc
cheers
Markus
Thanks for the comment. As Markus suggested, the problem is that line breaks don’t count as glyphs, so the font engine that we’re using doesn’t return any information for those (it does count spaces though for some reason).
Unfortunately I don’t really have an easy fix for this since it isn’t our code that is returning the information. The best option would be for me to manually search the string for line breaks in advance and then insert them back into the output, which is what you may want to do as well if you need a quick fix.
Alternatively, you might also just be able to check for changes in the vertical layout position - although that could get confused with automatic word wrapping depending on what your source text is like.
I implemented the check using the .origin.y in comparison with the previous element from a buffer I a using in my script. So not impossible, was just hoping there might be a way to get \n as an element.
But thanks for the clarification, so I will continue to use that approach!