Hi,
I'm trying to use inkscape to open a svg file generated by lilypond but I'm having some problems: inkscape shows boxes instead of music notes. I do have the corrected fonts installed (have tried them with other programs).
I could narrow the problem down to this:
1. put the emmentaler fonts in ~/.fonts 2. run fc-cache 3. open inkscape, select the emmentaler font from the text tool 4. type ctrl-u e125, that should give me a notehead glyph but I get a non-printable character message instead
this url has the otf font and a "print out" with the font glyphs (from fontforge, useful to know the unicode code) in case someone feels like taking a look:
http://www.pedrokroeger.net/inkscape/
I thought the problem was related to some library, but firefox can render this beautifully using the emmentaler font:
<html>  </html>
I'm using inkscape 0.43, fontforge 20060125, and pango 1.10.2.
Any ideas or pointers?
Best regards,
Pedro Kröger
On 2/20/06, Pedro Kroger <pedrokroeger@...155...> wrote:
Any ideas or pointers?
One idea is that e125 is in a Private Use Area in Unicode. I never used that so I don't know how programs are supposed to handle those codes, but I suspect there are some differences.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Feb 20, 2006, at 12:05 PM, Pedro Kroger wrote:
Hi,
I'm trying to use inkscape to open a svg file generated by lilypond but I'm having some problems: inkscape shows boxes instead of music notes. I do have the corrected fonts installed (have tried them with other programs).
Are you *sure*??
What other fonts did you use, and with what methods?
...
I thought the problem was related to some library, but firefox can render this beautifully using the emmentaler font:
<html>  </html>
I'm using inkscape 0.43, fontforge 20060125, and pango 1.10.2.
Any ideas or pointers?
Well... there are two issues.
First of all, that font is using the Private Use Area range in Unicode. U+E000 to U+F8FF. That's one sign of complication. There are many ways to approach this, but on is to have multiple mapping tables in the font that are used in different situations.
The second main issue is that the SVG file is using SVG fonts, which Inkscape does not yet support. That actually embeds the glyph data as drawing commands right in the SVG file.
One thing I did was a simple test. I installed that font on my Mac (OS X 10.4.5) and then tried to do the same html test. I used <font face="emmentaler"> in the html. It did change the glyph style in Safari, but it was still a box. I then tried in FireFox 1.5.0.1 and saw the same failure.
This would indicate to me that there is possibly something wrong with the structure of that font, as Macs are known for their strong typography support. The file is OTF and not TTF, so I can't run my little font analyzing tool I did a while back. I guess at some point I could update that if needed.
Further complicating things is the way in which you generated that font dump. You used FontForge to create that, however... FontForge appears to be the tool used to create the font in the first place. Therefore, it's very likely that FontForge can read things since it wrote them and has certain expectations that match, but a third-party pathway can expose problems.
Which other applications can you use this font with? Which OS are you running? Have you tried in a range of GTK+ applications?
Oh, another thing... I played with the font some in Font Book (the default font tool in OS X), and although things were all listed in previewing the font's repertoire, when I tried to edit its preview to include U+E125, it showed up there as a missing glyph.
So, although there might be some Inkscape-specific bug, it's looking more like a slightly malformed font that certain rendering libs fail with.
On 2/20/06, Jon A. Cruz <jon@...204...> wrote:
Are you *sure*??
yes
What other fonts did you use, and with what methods?
when I said "fonts" I meant the emmentaler set of fonts:
emmentaler-11.otf emmentaler-13.otf emmentaler-14.otf emmentaler-16.otf emmentaler-18.otf emmentaler-20.otf emmentaler-23.otf emmentaler-26.otf
One thing I did was a simple test. I installed that font on my Mac (OS X 10.4.5) and then tried to do the same html test. I used <font face="emmentaler"> in the html. It did change the glyph style in Safari, but it was still a box. I then tried in FireFox 1.5.0.1 and saw the same failure.
well, I just tested this here with firefox 1.5.0 and it worked:
<html> <font face="emmentaler"></font> </html>
Which other applications can you use this font with? Which OS are you running? Have you tried in a range of GTK+ applications?
no. I couldn't figure out how to insert unicode chars by hexadecimal numbers. I found in some documentations that I should press C+S+hexadecimal number, but it didn't work for me.
Pedro
On Feb 21, 2006, at 1:24 AM, Pedro Kroger wrote:
no. I couldn't figure out how to insert unicode chars by hexadecimal numbers. I found in some documentations that I should press C+S+hexadecimal number, but it didn't work for me.
The the fallback way is to use a character map and copy them over.
Under GNOME you should have the "Character Map" accessory.
Under KDE there's kcharselect (not sure which name it shows up under for the menus, but should be something like "KCharacterSelector")
Just copy from those and paste into other GTK+ apps
Pedro Kroger wrote:
I put the font, Emmentaler-20, in FontLab 4.6, and found it to be okay, showed all the music symbols between E100 through E266. Now as for Inkscape knowing how to handle such a Unicode OTF font, I don't have a clue.
Frank
On Feb 20, 2006, at 1:40 PM, frank gaude' wrote:
Pedro Kroger wrote:
I put the font, Emmentaler-20, in FontLab 4.6, and found it to be okay, showed all the music symbols between E100 through E266. Now as for Inkscape knowing how to handle such a Unicode OTF font, I don't have a clue.
See my response.
There's something not quite right about the font. It might take some low-level poking to see what's up. (With TTF files, the first thing I'd look to was multiple cmap tables).
Jon A. Cruz wrote:
On Feb 20, 2006, at 1:40 PM, frank gaude' wrote:
Pedro Kroger wrote:
I put the font, Emmentaler-20, in FontLab 4.6, and found it to be okay, showed all the music symbols between E100 through E266. Now as for Inkscape knowing how to handle such a Unicode OTF font, I don't have a clue.
See my response.
There's something not quite right about the font. It might take some low-level poking to see what's up. (With TTF files, the first thing I'd look to was multiple cmap tables).
Well, Jon, I installed the font in Win XP Pro SP2, opened it in InDesign CS, used the Glyphs feature and ID showed all the musical symbols therein. I can't see anything wrong with it. FontLab shows it to be a good font, no problem with cmap tables. Under the Georgian, 1257 Baltic, Unix/Relcom Cyrillic KOI-8R, and 1252 Latin 1 formats all looked as it should, you just have to know how to handle the E100 - E266 code range. Most Adobe products do.
Frank
On Feb 20, 2006, at 2:08 PM, frank gaude' wrote:
Well, Jon, I installed the font in Win XP Pro SP2, opened it in InDesign CS, used the Glyphs feature and ID showed all the musical symbols therein. I can't see anything wrong with it. FontLab shows it to be a good font, no problem with cmap tables. Under the Georgian, 1257 Baltic, Unix/Relcom Cyrillic KOI-8R, and 1252 Latin 1 formats all looked as it should, you just have to know how to handle the E100 - E266 code range. Most Adobe products do.
I did a little more experimenting.
I still could not get at things on my OS X box with that font. I'd also installed gedit to have a standard app to check with also.
I did track down a different .otf font that had some glyphs in the Private Use Area. First of all, OS X seemed happy with it and it's glyphs in the expected locations. Then I ran things under some GTK+ apps. Using gucharmap and gedit I was able to run through the private use area characters in the other font, but not with Emmantaler. The other font also worked for Inkscape then, but not Emmantaler.
The .otf I tried had been made with PfaEdit 1.0, and Emmantaler seems to be done with FontForge 1.0 (the later renaming of PfaEdit).
Anyway, it's looking at the least that the font itself is exposing some base problems. Though there's also a strong possibility that it's actually some problem in the font. So I'll be digging into it to see if I can track anything down in the structure of the font in question.
Quoting "Jon A. Cruz" <jon@...204...>:
There's something not quite right about the font. It might take some low-level poking to see what's up. (With TTF files, the first thing I'd look to was multiple cmap tables).
Have we verified that private range characters map and display correcly in Inkscape in general right now? I know we've had problems in the past...
-mental
On Feb 20, 2006, at 2:31 PM, mental@...32... wrote:
Quoting "Jon A. Cruz" <jon@...204...>:
There's something not quite right about the font. It might take some low-level poking to see what's up. (With TTF files, the first thing I'd look to was multiple cmap tables).
Have we verified that private range characters map and display correcly in Inkscape in general right now? I know we've had problems in the past...
That's probably something to take up on the devel mailing list for follow-up.
I seem to recall some issues that were solved by someone going for U +E100 instead of U+E000, but details are a bit fuzzy.
But at the moment we have a hard OS limit that the simple test that worked for the user fails for me over here on OS X. The same *might* be involved with versions of Pango, etc.
Having some details from the user on OS, and whether or not things work properly for other GTK+ apps will help narrow things down.
Oh, and perhaps even a test of opening that .svg file itself directly in FireFox 1.5. For me, things come up to small and squished together to tell accurately.
On 2/20/06, Jon A. Cruz <jon@...204...> wrote:
Having some details from the user on OS, and whether or not things work properly for other GTK+ apps will help narrow things down.
I use linux (sourcemage linux), gtk+ 2.8.11. The problem also happens with ubuntu breezy.
Pedro
On Feb 20, 2006, at 12:05 PM, Pedro Kroger wrote:
- type ctrl-u e125, that should give me a notehead glyph but I get a
non-printable character message instead
You are actually encountering two issues here. One is that the glyph is not showing up. The second is that Inkscape is not allowing non- printable characters to be input via it's Ctrl-u method.
For that entry problem, go ahead and file a bug report that Inkscape's input does not allow private use area characters to be entered. That, at least, can be fixed in Inkscape's code.
On 2/20/06, Jon A. Cruz <jon@...204...> wrote:
For that entry problem, go ahead and file a bug report that Inkscape's input does not allow private use area characters to be entered. That, at least, can be fixed in Inkscape's code.
Maybe it can, but it's not the right way to do it. We use a library function to check whether a character is printable, so the right way is to raise this issue with the library maintainers.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 2/20/06, bulia byak <buliabyak@...155...> wrote:
Maybe it can, but it's not the right way to do it. We use a library function to check whether a character is printable, so the right way is to raise this issue with the library maintainers.
??what library is that? (so I can check and see if the version I have here is "good")
One of the main lilypond developers says the svg file is working for he, so I can't help but think that this is related to some library version issue.
Pedro
On Feb 21, 2006, at 1:35 AM, Pedro Kroger wrote:
On 2/20/06, bulia byak <buliabyak@...155...> wrote:
Maybe it can, but it's not the right way to do it. We use a library function to check whether a character is printable, so the right way is to raise this issue with the library maintainers.
¬what library is that? (so I can check and see if the version I have here is "good")
glib. But that call isn't expected to be complicating things here.
One of the main lilypond developers says the svg file is working for he, so I can't help but think that this is related to some library version issue.
Well... yes, but probably it is some *font* library issue. Either the font system is flawed or the font itself is.
Given that the specific font in question does not work properly on a mac, the font is coming under suspicion. Either it's doing something that the font handling libraries in GTK/Pango and OS X both don't expect, or it's doing something incorrectly.
BTW, I'm on on Pango 1.10.1 here for GTK+ stuff, and OS X 10.4.5.
Oh, but I don't think there's anything going wrong on Lilypond's side of things.
participants (5)
-
unknown＠example.com -
bulia byak -
frank gaude' -
Jon A. Cruz -
Pedro Kroger