Open sasensi opened 6 months ago
It seems that Photoshop puts \u0003
symbol for new line, but also indicates that the line is broke in that spot in psd.engineData field, unfortunately engineData field is not yet implemented in ag-psd, there's no documentation for that object and it's compressed in a weird way that makes it really hard to decipher. invalidateTextLayers: true
clears engineData field so that's why the information about that line break is lost.
@Agamnentzar, thank you for your quick response, ok, I see. So is implementing engineData support in ag-psd something that you plan to do or not really ? Also, is there something I can help with in order to support this use case ?
The problem is that the data in that section looks like this:
And I have no way of figuring out which numbers map to what property names, I managed to figure out some of the fields by just changing fields in Photoshop and seeing which one of these change values, but that doesn't work for all of the fields, so I'm stuck at this point until I have some way to find what these fields are. (My guess for why it is this way is that they wanted to compress the data so they replaced property names with numbers, and Photoshop has some internal dictionary that can translate numbers to names)
Did you try if it works without invalidateTextLayers: true
?
@Agamnentzar, I see quite clearly the problem because I once built a rough .ai writer (less advanced than yours though) and had to deal with this kind of data also š
And the way I went was exactly what you describe: guessing each piece of data meaning by trial and error.
And since it's not documented, I guess that it's the only way unfortunately.
I also tried without invalidateTextLayers: true
but it doesn't work neither.
Hello and once again, thank you for the great work with this library which helps me so much ! š
Working with the following file: input.zip
That looks like this in Photoshop: Notice the text has a paragraph spacing set so the line 3 is separated from the line 2 by the expected gap but this gap is not between the line 1 and 2 because they are separated by a carriage return character and not a line break character.
So if we take this file, read it and write it using the library, like this:
It then looks like this: For some reason, the carriage return character is not preserved.
I tried to play with it a bit using this code, to try all possible line breaks characters that I knew but none seems to produce the expected result:
And here's the visual result:
Hoping you can help with this š¤