Pango errors when generating PostScript (but not SVG) #14

marnen · 2017-12-11T23:19:23Z

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?

The text was updated successfully, but these errors were encountered:

moinejf · 2017-12-13T12:00:30Z

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 · 2017-12-13T18:03:36Z

@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 · 2017-12-13T18:44:42Z

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 · 2018-08-28T14:14:25Z

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

moinejf · 2018-08-28T14:58:36Z

Anyway, there is no solution for this problem.

moinejf · 2018-09-03T18:18:20Z

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 · 2018-09-03T19:24:38Z

@moinejf:

What were these messages?

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

Issue #14.

moinejf · 2018-09-09T15:16:34Z

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 · 2018-09-09T15:33:57Z

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 · 2019-04-27T17:26:25Z

@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 · 2021-01-08T19:31:21Z

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 · 2021-01-09T09:25:38Z

@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 · 2021-01-09T12:15:16Z

@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?

…visible rests Issue #14.

moinejf · 2021-01-10T17:34:36Z

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

catellie · 2021-01-10T18:04:34Z

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

catellie · 2021-01-10T18:08:24Z

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

lewdlime closed this as completed Aug 28, 2018

moinejf reopened this Sep 3, 2018

moinejf added a commit that referenced this issue Sep 9, 2018

fix: better handling of fonts when pango

4f352f6

Issue #14.

PangPangpeng mentioned this issue Jul 25, 2020

Segment Fault format.c:1412 in set_font #76

Open

moinejf added a commit that referenced this issue Jan 10, 2021

fix: bad placement of chord symbols when in a music line with only in…

27d0bc6

…visible rests Issue #14.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Pango errors when generating PostScript (but not SVG) #14

Pango errors when generating PostScript (but not SVG) #14

marnen commented Dec 11, 2017 •

edited

Loading

moinejf commented Dec 13, 2017

marnen commented Dec 13, 2017

moinejf commented Dec 13, 2017

marnen commented Aug 28, 2018

moinejf commented Aug 28, 2018

moinejf commented Sep 3, 2018 •

edited

Loading

marnen commented Sep 3, 2018 •

edited

Loading

moinejf commented Sep 9, 2018 •

edited

Loading

marnen commented Sep 9, 2018 •

edited

Loading

marnen commented Apr 27, 2019

catellie commented Jan 8, 2021 •

edited

Loading

moinejf commented Jan 9, 2021

catellie commented Jan 9, 2021

moinejf commented Jan 10, 2021

catellie commented Jan 10, 2021

catellie commented Jan 10, 2021

Pango errors when generating PostScript (but not SVG) #14

Pango errors when generating PostScript (but not SVG) #14

Comments

marnen commented Dec 11, 2017 • edited Loading

moinejf commented Dec 13, 2017

marnen commented Dec 13, 2017

moinejf commented Dec 13, 2017

marnen commented Aug 28, 2018

moinejf commented Aug 28, 2018

moinejf commented Sep 3, 2018 • edited Loading

marnen commented Sep 3, 2018 • edited Loading

moinejf commented Sep 9, 2018 • edited Loading

marnen commented Sep 9, 2018 • edited Loading

marnen commented Apr 27, 2019

catellie commented Jan 8, 2021 • edited Loading

moinejf commented Jan 9, 2021

catellie commented Jan 9, 2021

moinejf commented Jan 10, 2021

catellie commented Jan 10, 2021

catellie commented Jan 10, 2021

marnen commented Dec 11, 2017 •

edited

Loading

moinejf commented Sep 3, 2018 •

edited

Loading

marnen commented Sep 3, 2018 •

edited

Loading

moinejf commented Sep 9, 2018 •

edited

Loading

marnen commented Sep 9, 2018 •

edited

Loading

catellie commented Jan 8, 2021 •

edited

Loading