https://bugs.documentfoundation.org/show_bug.cgi?id=165396
--- Comment #8 from V Stuart Foote <[email protected]> --- (In reply to Dave Gilbert from comment #7) > Yeh I can imagine something like getting that data and looking at the width > of 'i' and 'm' say and then some heuristic to choose the size of the > fallback font rather than what we were told; or maybe even to pick the right > fallback? > > Anyway, this sounds kind of doable, but is very much a heuristicy type thing > we'd have to play with. But ideally it doesn't even come from a fallback, instead we should try harder to use the embedded subset font glyphs recorded to Font directories in the PDF. Unfortunately they won't follow Unicode, and absent a /ToUnicode handling inside the PDF, normally get arbitrary encoded points to assemble the text spans. But then that is how the pdfium Insert filter parses the PDF (to BMP image, with high fidelity to original PDF, but we've asked option to also deliver vector objects). If we were able to better use the subset fonts when filter imported (poppler -> cairo object) then only additional edits/changes to the draw text shapes might need fallback font. But suspect that would be a lot of dev effort for minimal returns--LibreOffice is not a PDF editor, and the current filter import of PDF text objects to runs within Draw text shapes is really not too bad and suitable to majority of uses. -- You are receiving this mail because: You are the assignee for the bug.
