https://bugs.freedesktop.org/show_bug.cgi?id=62846
--- Comment #11 from Jonathan <[email protected]> --- 1. I get the same result so my build is also using the internal PDF backend. The only explanation I can find is that you have somehow not incorporated the patches. That is, the behaviour you are showing is exactly that of the unpatched sources. 2. I've found out why I got strange behaviour. The problem is related to my first patch (trailing multicharacter glyph...). You can't map the last character from the sequence and map it to the rest of the characters in the input file because the sequence may not be the final sequence in the file. I can see no obvious solution. The problem (or at least one problem) is that pCharPosAry, which PDFWriterImpl::drawLayout uses to construct the Unicode mapping, isn't really right for the job. The 'Experimental patch' seems to go some way to improving this but there is still the problem of knowing the number of characters that correspond to the final glyph in a sequence. It's not just a matter of fixing this in graphite_layout.css because it must remain compatible with GenericSalLayout::GetNextGlyphs I suspect the answer is in the comments in pdfwriter_impl.cxx to the effect that the Unicode mapping has been implemented with a quick fix and really needs to be done properly. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
