Pango errors when generating PostScript (but not SVG)

[marnen]

I'm using abcm2ps 8.13.17 and pango 1.40.14, both installed through Homebrew on Mac OS X 10.12 (Sierra). When I attempt to use abcm2ps to process ABC files containing certain non-ASCII characters (see below for more on which ones), it works perfectly for SVG output, but for PostScript output, abcm2ps crashes with the following error messages:

``` (process:74759): GLib-GObject-WARNING **: invalid cast from 'PangoCairoCoreTextFont' to 'PangoFcFont' (process:74759): Pango-CRITICAL **: pango_fc_font_lock_face: assertion 'PANGO_IS_FC_FONT (font)' failed warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 warning: freetype error 35 (process:74759): Pango-CRITICAL **: pango_fc_font_unlock_face: assertion 'PANGO_IS_FC_FONT (font)' failed ```

The characters that can trigger this error include ’ U+2019 RIGHT SINGLE QUOTATION MARK and — U+2014 EM DASH, as well as letters from non-Roman scripts such as Cyrillic, but not × U+00D7 MULTIPLICATION SIGN. I've tried turning off Pango with the --pango 0 option, but while that prevents the crash, it also means that these characters don't show up in the output. Help?

[moinejf]

I installed pango in my machine (ARM VoidLinux) and I got the same problem. After some investigations, I found that this is due to a generation option of freetype2. Without the right option, there is no way to get the font and glyph names of the characters. This generation depends on the software distribution. I alerted the ABC mailing-list about this problem to know which distros are concerned. Anyway, you must disable pango. Then, the specific non-ASCII characters must be defined by %%glyph for correct rendering (see http://moinejf.free.fr/abcm2ps-doc/glyph.xhtml). The other solution is to generate SVG files with abcm2ps or abc2svg...

[marnen]

@moinejf:

After some investigations, I found that this is due to a generation option of freetype2. Without the right option, there is no way to get the font and glyph names of the characters.

I wonder if that's actually the cause. I know that Lilypond on the same machine has no trouble with these characters (and AFAIK it uses Pango and, I think, Freetype to render them).

This generation depends on the software distribution.

FWIW, I'm using Pango 1.40.14 and Freetype 2.8.1, both installed with Homebrew.

Anyway, you must disable pango. Then, the specific non-ASCII characters must be defined by %%glyph for correct rendering (see http://moinejf.free.fr/abcm2ps-doc/glyph.xhtml).

I don't see how this is practical. I want to simply type arbitrary non-ASCII characters into ABC files and have them show up correctly in PDF output as they do in SVG. Why should it be the user's responsibility to mess around with a %%glyph list to do that? Shouldn't abcm2ps already support this? The docs mention that Ghostscript already contains such a glyph list; perhaps abcm2ps should read it directly?

[moinejf]

I wonder if that's actually the cause. I know that Lilypond on the same machine has no trouble with these characters (and AFAIK it uses Pango and, I think, Freetype to render them).

There are 2 ways of using pango + freetype for PostScript output:

• either generate the whole PS document with cairo/pango/freetype. I think that Lilypond uses this,
• or generate manually the PS document asking pango/freetype to give the font and the name of the glyphs. That what is done in abcm2ps.

Changing the abcm2ps mechanism to Lilypond's asks for a full rewrite of the whole program, and I stopped any new developments on it.

FWIW, I'm using Pango 1.40.14 and Freetype 2.8.1, both installed with Homebrew.

As I said, there is a generation option in freetype. The distribution people (Debian, VoidLinux, Mint.. for GNU/Linux) are free to set or not this option. The source is the same, only the binary is different.

I don't see how this is practical. I want to simply type arbitrary non-ASCII characters into ABC files and have them show up correctly in PDF output as they do in SVG. Why should it be the user's responsibility to mess around with a %%glyph list to do that? Shouldn't abcm2ps already support this? The docs mention that Ghostscript already contains such a glyph list; perhaps abcm2ps should read it directly?

This is the main problem with PostScript: this old language does not know Unicode. You may see that, when run, abcm2ps does not read any external file but the ones of the command line. Yes, some glyph names may be get from the GhostScript distribution (Resource/Decoding/Unicode), but this file is big (135Kb for 4500 characters), and it deals only about the fonts known by GhostScript (Type1). And, more, the glyph names are not standardized: each font may have its own naming system. So, when moving to Unicode, I naturally went to pango, but, now, it seems that people are not interested anymore by PostScript, and so I am!

Anyway, if you want to display random unicode characters in PostScript, you may easily create a ABC file containing a %%glyph line for each character found in the GhostScript resource...

[marnen]

@leesavide Has this issue been fixed? If not, why close it?

[moinejf]

Anyway, there is no solution for this problem.

[moinejf]

After more investigations, I found that pango in abcm2ps works fine with TrueType fonts, as FreeFont and Liberation, but not with PostScript Type1 or X11 fonts.

In your first message, you were writing:

for PostScript output, abcm2ps crashes with the following error messages:

What were these messages?

[marnen]

@moinejf:

What were these messages?

If you expand the disclosure triangle next to "Details", you'll see them.

[moinejf]

The tag <details> was not handled by my old palemoon browser so I did not see the messages.

Well, there were problems with pango. I made some changes for that in the commit 4f352f6 (version 8.14.0). May you check if the program works better for you now?

[marnen]

The tag <details> was not handled by my old palemoon browser so I did not see the messages.

Hmm, strange. I thought that browsers that didn’t understand a container tag would just show the contents.

Well, there were problems with pango. I made some changes for that in the commit 4f352f6 (version 8.14.0). May you check if the program works better for you now?

Sure, I’ll try it when I have a chance. Thanks!

[marnen]

@moinejf This is better, at least. I get boxes instead of the right characters (even though I think they're present in the font), but at least the program no longer crashes. Thanks.

[catellie]

Presumably related to the above: For kicks I compiled this under TermUX (Android) where it is unable to find pangocairo (to my knowledge it is not yet available), but it still mostly works. The only problem is that the generated postscript blindly uses ysn0 which is undefined, so I had to insert the definition "/yns0{-74.0 add}!" before the first use and that makes ps2pdf perfectly happy to generate a working PDF even locally under TermUX, which is good enough for my proof of concept. Hopefully this can help someone else who runs into this.

[moinejf]

@catellie I am using a ARM board and I generate the abcm2ps static binaries with PIE and the musl library (no pango support). It must run in Android. As I have no problem with 'yns'x, I'd be happy to get a small example of a ABC tune and the generated .ps so I could compare with my result. In the other way, I have put my binary (627KB) in my site so you can try it: http://moinejf.free.fr/abcm2ps

[catellie]

@moinejf I've just tried your binary and strangely it appears to produce identical results under my TermUX system. Here is the ABC tune I'm using:

X:1 % T:Vollkadenz % M:C L:1/4 Q:160 K:C "C"x4 | "F"x4 | "B-"x4 | "E-"x4 | "A-"x4 | "D-"x4 | "G7"x4 | "C"x4 || "C"e4 | "F"e4 | "B-"d4 | "E-"d4 | "A-"c4 | "D-"c4 | "G7"B4 | "C"B4 || "C"edcd | "F"edce | "B-"dcBc | "E-"dcBd | "A-"cBAB | "D-"cBAc | "G7"BAGA | "C"BGEC || "C"e2-e/d/c/d/ | "F"e2-e/d/c/e/ | "B-"d2-d/c/B/c/ | "E-"d2-d/c/B/d/ | "A-"c2-c/B/A/B/ | "D-"c2-c/B/A/c/ | "G7"B2-B/A/G/A/ | "C"BGEC ||

Examining the result closer, I think the problem is the guitar chords rendering: Here is a snippet from the title to the first chord:

% --- title Vollkadenz 340.8 4.0 M 20.0 F2 (Vollkadenz)showc 0 -12.00 T % --- font 20.0 F2 33.0 -17.0 M gsave 0.70 dup scale 8 3 RM currentpoint hd 21 su grestore 13.3 0 RM 15.0 F3 (= )show (160)show 12.0 F0 34.5 8.4 yns0 M (C)gcshow

So perhaps this is a more basic problem?

[moinejf]

@catellie The problem should be fixed by the commit 27d0bc6. I uploaded the new ARM binary.

[catellie]

Excellent! I just rebuilt on TermUX with the latest source and it works as expected. :bow:

[catellie]

A bit of an edge case now that I think about it - I just grabbed the first abc file I had around... :shrug: