Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
marnen opened this issue Dec 11, 2017 · 16 comments
Open

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

marnen opened this issue Dec 11, 2017 · 16 comments

Comments

@marnen
Copy link

marnen commented Dec 11, 2017

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
Copy link
Collaborator

moinejf commented Dec 13, 2017

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
Copy link
Author

marnen commented Dec 13, 2017

@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
Copy link
Collaborator

moinejf commented Dec 13, 2017

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
Copy link
Author

marnen commented Aug 28, 2018

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

@moinejf
Copy link
Collaborator

moinejf commented Aug 28, 2018

Anyway, there is no solution for this problem.

@moinejf
Copy link
Collaborator

moinejf commented Sep 3, 2018

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?

@moinejf moinejf reopened this Sep 3, 2018
@marnen
Copy link
Author

marnen commented Sep 3, 2018

@moinejf:

What were these messages?

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

moinejf added a commit that referenced this issue Sep 9, 2018
@moinejf
Copy link
Collaborator

moinejf commented Sep 9, 2018

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
Copy link
Author

marnen commented Sep 9, 2018

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
Copy link
Author

marnen commented Apr 27, 2019

@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
Copy link

catellie commented Jan 8, 2021

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
Copy link
Collaborator

moinejf commented Jan 9, 2021

@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
Copy link

catellie commented Jan 9, 2021

@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 added a commit that referenced this issue Jan 10, 2021
@moinejf
Copy link
Collaborator

moinejf commented Jan 10, 2021

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

@catellie
Copy link

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

@catellie
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants