bugFree UCS Outline Fonts - Bugs: bug #40275, Inconsistent glyph names of...


bug #40275: Inconsistent glyph names of russian characters

Submitted by:  Vadim <vadimr>
Submitted on:  Tue 15 Oct 2013 09:37:46 AM UTC  
Category:  individual character(s) Severity:  3 - Normal
Item Group:  glyph name issue Status:  Fix posted
Privacy:  Public Assigned to:  Steve White <Stevan_White>
Open/Closed:  Open Release:  2012-05-03

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Thu 24 Oct 2013 08:18:21 AM UTC, comment #8:

Sorry, I had to revert that change. A FontForge glitch causes global trouble when re-naming glyphs -- it re-names any glyph containing the changed glyph as a substring. I don't even know how I'm going to solve this.

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Wed 23 Oct 2013 09:28:33 PM UTC, comment #7:

I just committed a change to serif normal, which brings the names of the main Slavic glyphs into agreement with the other faces, as is proper.

Not sure about the rest of the Cyrillic glyphs. I probably should write a script, that identifies inconsistencies. Another day.

No, I won't ask why people write broken software. But this isn't the place to fix that.

Again, there are much better ways of filling in the ToUnicode table than the broken, awful glyph naming convention.

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Wed 16 Oct 2013 05:10:34 PM UTC, comment #6:

Further examples (tests2.pdf) show that ToUnicode can become broken after some processing, if glyph names are not in AGL. Please don't ask why someone would process files like that. It's not the point here. People do all kind of things with their files and then leave happy that job is done (in whatever way they came up with), but files, though visually correct PDF, are broken.

For this test I used OTF fonts FreeSerif.otf & FreeSerifBold.otf.

1. I typed couple of lines in LibreOffice, then output postscript to file (ps.ps), then produced PDF

gswin32c -sDEVICE=pdfwrite -o pdf.pdf ps.ps

Cyrillic in plain typeface in PDF is un-extractable and un-searcheable - ToUnicode broken, though bold is OK.

2. I exported PDF from same LibreOffice document (libre.pdf), converted to PS with xpdf's pdfto ps, then converted back to PDF.

xpdfbin-win-3.03\pdftops libre.pdf libre_xpdf.ps
gswin32c -sDEVICE=pdfwrite -o libre_xpdf_gs.pdf libre_xpdf.ps

Same issue with plain typeface.

3. Same line of text I exported from Adobe Indesign (test.pdf), then saved it to postscript from Acrobat (test_ps_from_acro.ps), then open PS back in Acrobat and saved PDF (test_ps_from_acro_and_back_to_pdf.pdf). All settings were "Acrobat default" and "High quality print". Same issue with plain typeface in final PDF.

(file #29388)

Vadim <vadimr>
Wed 16 Oct 2013 05:08:13 PM UTC, comment #5:

Here are test files (test.zip) and procedure. Original is _18_1.eps. Author used Tymes New Roman Cyr for Cyrillic, but as sometimes happens, because of bugs/limitations/neglect of postscript export of application, EPS ends up with Times Roman and Win-ANSI encoding. To fix it, and to convert EPS to portable PDF with embedded correct fonts, I used Ghostscript - supplied it with:
- Type1 fonts, which I made like this

ttf2pt1 -b -l russian c:\test\FreeSerif.ttf

- fontmap file (from Times to FreeSerif) and
- CP1251 encoding (found e.g. here: https://raw.github.com/gnuplot/gnuplot/master/term/PostScript/cp1251.ps).

All files are in c:\test\ folder (Windows machine), then:

gswin32c -sDEVICE=pdfwrite -dEPSCrop -Ic:\test\ -o c:\test\out_FreeSerif.pdf cp1251.ps -c "/definefont {dup /Encoding CP1251Encoding put definefont} bind def" -f c:\test\_18_1.eps

As you can see in supplied out_FreeSerif.pdf, Regular typeface fails (because it uses names not in AGL), while Bold is OK. Note that ToUnicode resource is correct -- because glyph names in Encoding array conform to AGL -- so Ghostscript builds it even if it can't find glyphs in font. Weird.

Also included is out_Liberation.pdf produced by the same rules -- to show that there's no problem with Liberation fonts and to show what the result should be.

(file #29387)

Vadim <vadimr>
Wed 16 Oct 2013 08:14:40 AM UTC, comment #4:

Hi again,

Could you go into more detail as to how Ghostscript failed?

Maybe send us a small test file or example of the effect?

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Tue 15 Oct 2013 09:01:20 PM UTC, comment #3:

Hi Vadim,

No need to excuse perfectionism. I agree it isn't right, and something needs to be done about it.

We have no interest in the AGL. It's a bad idea. This is a repeated topic in these reports. Will discuss more off-line.

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Tue 15 Oct 2013 05:22:45 PM UTC, comment #2:

it's annoyance for perfectionists, rather, who are never content and always spoil good folks fun :-).

Well, I found this issue while working on a small project, part of it was using free, metrically equivalent to TNR family, cyrillic Type1 (I used ttf2pt1 to convert). These fonts, along with CP1251 encoding, I supplied to Ghostscript to convert a bunch of EPS files to PDF, while replacing incorrect references to Times Roman and WinANSI encoding (it was Times New Roman Cyr (CP1251) in original application). As it turned out, GS can find glyphs as long as their names conform to AGL (be it ACyrillic or uni0410 or afii10017) -- thus, FreeSerif Bold with "ACyrillic" was OK, but FreeSerif Regular with "Az" failed. In retrospect, I think I could edit CP1251.ps file, and using Type1 instead of TTF was questionable -- but I finished abandoning FreeSerif and used Liberation font family.

Plus, I think I can easily produce an example (no less convoluted than example above, someone could say), in which ToUnicode map in PDF will be lost after pdf - ps - pdf convertion -- why users do that is beyond the scope here. E.g. distiller will not be able to build new correct ToUnicode table, because font encoding uses names outside of AGL. We'll finish with a document which can not be indexed, text can not be extracted, good for OCR-only, etc. -- and there are already too many such documents, unfortunately.

Well, perfectionism or not, it's simply not right, when 2 faces of the same font use completely different glyph names, not for a mature project. Not exactly an urgent issue, but worth fixing for good.

Vadim <vadimr>
Tue 15 Oct 2013 02:29:13 PM UTC, comment #1:

Hi, Vadim,

Yes, I'm well aware of it. A Russian contributor a few years back slipped that in -- he was particularly interested in Old Church Slavonic I think. I haven't had the heart to (shall we say) update the names.

My loose policy is to make glyph names to reflect (somehow) the Unicode names.

Besides the annoyance for developers, how is it a problem for you?

Steve White <Stevan_White>
Project AdministratorIn charge of this item.
Tue 15 Oct 2013 09:37:46 AM UTC, original submission:

In FreeSans Regular font, russian letters have glyph names

Acyrillic (u0410)
Becyrillic (u0411)
Vecyrillic (u0412)
Gecyrillic (u0413)

As I understand, this is your choice (instead of "afiiXXXXX" or "uniXXXX") and is not to be discussed. At least, these names conform to Adobe Glyph List.

But, in FreeSerif Regular, the same glyphs are named


It's a very strange choice. You probably know, these names are long out-dated, they were used before 1918 alphabet reform -- nearly 100 years ago! Whoever came up with an idea, maybe they thought it would be funny, a bit old-fashioned and therefore "cute", a touch of Russian Imperial grandeur or "great culture lost" or something. And funny it is, but unfortunately has nothing to do with modern grammar and cyrillic encodings.

This "dualism" is found in all 12 fonts of the project. I think it's a bug and may better be fixed.

Vadim <vadimr>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #29388:  tests2.zip added by vadimr (224KiB - application/zip)
file #29387:  test.zip added by vadimr (316KiB - application/zip)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by Stevan_White (Posted a comment)
  • -email is unavailable- added by vadimr (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-10-23 Stevan_White StatusNeed info => Fix posted
    2013-10-16 vadimr Attached File- => Added tests2.zip, #29388
    2013-10-16 vadimr Attached File- => Added test.zip, #29387
    2013-10-15 Stevan_White StatusNone => Need info
        Assigned toNone => Stevan_White

    Back to the top

    Powered by Savane 3.4