https://bugs.documentfoundation.org/show_bug.cgi?id=89471
V Stuart Foote <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #17 from V Stuart Foote <[email protected]> ---
(In reply to Eyal Rozenberg from comment #16)
> (In reply to V Stuart Foote from comment #15)
> > the ipdf (pdfium based) cleanly inserts all RTL text from PDF--but
> > fails miserably on break (bad font fallback from looks of it).
>
> What's the "ipdf" as opposed to "pdfio"?
ipdf using Google chrome project's pdfium
https://opengrok.libreoffice.org/xref/core/vcl/source/filter/ipdf/
pdfio (legacy from the Oracle PDF extension, takes things through popler)
https://opengrok.libreoffice.org/xref/core/sdext/source/pdfimport/
>
> > Unicode for glyphs are not recorded to PDF
>
> How could this be possible? Could you elaborate?
Adobe defined Glyph lists (AGLFN) as opposed to OpenType tables--with results
added to /ToUnicode table structure of glypnhs used in the PDF. So Unicode is
always involved--should have thought a bit more about that. The glyps are
recorded into the PDF in the sequence they occur. What is mishandled in the
pdfio filter is recognition that the text run is from a script entered RTL.
IIUC Hebrew and Arabic Unicode ranges have Unicode bidirectional ranges
identifying them as RTL--that they are not recognized as such on import
suggests the filter is not making use of the ICU bidi library.
@Khaled, have you ever looked at the PDF import filters? Does it use the ICU
libs? And if not, it probably should, right?
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
