https://bugzilla.redhat.com/show_bug.cgi?id=1009650
vishalvvr vishalvijayraghavan@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |MODIFIED
--- Comment #49 from vishalvvr vishalvijayraghavan@gmail.com --- Hello,
First of all sorry for such delayed reply. This bug seems to be not an liberation-fonts issue this is pdf compression issue. let me explain, for document portability pdf standards gave option to embedded subset fonts[1], which means instead of embedding entire font file it will only embedded a font file with only glyph/characters used in that document. This will reduce the pdf file size and also not required to install that font on system to view that document(for portability purpose).
Now while embedded subset of font which ever tool you use it just parsers entire fontfile and dump into temporary font file in unordered format i:e improper unicode to character mapping as shown in image attachment "Embedded subset liberationsans-bolditalic font with invalid charmap to unicode", and a valid character map should look like image attachment "Valid charmap to unicode endpoint in upstream liberationsans-bolditalic-font file".
Due to Embedded subset of liberation-font(by the tool which you are using to create/convert pdf) file the characters are mapped to invalid unicode point hence while you copy you get different characters rendered.
You can try it by yourself: 1. open your test attachment file using fontforge 2. choose any font from list shown 3. check if all characters are mapped to valid Unicode points
[1] https://publicatorcommunity.zmags.com/hc/en-us/articles/115002482043-Differe...
i18n-bugs@lists.fedoraproject.org