Hide Forgot
Description of problem: When the new content of copyright was pasted and saved, it showed as a broken character when cat the sfd file as plain-text. Version-Release number of selected component (if applicable): fontforge-20090622-2.fc12.x86_64 How reproducible: ALways Steps to Reproduce: 1. Open a font which has (c) in copyright field. (Element > FontInfo > Names > Copyright). 2. Replace the content with another text that also has the (c) sign. 3. Save the file. 4. cat the file in console (cat fontname.sfd|grep Copyright) Actual results: The (c) sign was displayed as other character. Expected results: The (c) sign was displayed as (c). Additional info: The font I was using is Liberation Fonts Mono Bold
Someone on the upstream lists suggests: >The copyright sign is not ASCII, so I would make sure there is a >consistent encoding. For instance the copyright symbol in the >Liberation font looks as if it is in Latin-1, but I use UTF-8 by >default on my system.
FYI, I start fontforge on Fedora in ja_JP.UTF-8. It is quite interesting that the original text Ascender (manufacturer) of copyright has the copyright sign both be displayed correctly on fontforge and cat. Also, the copyright sign didn't display correctly on Mono-Bold but was correct on Mono. However, I'd like to look into this info.
Ah ha. Another comment from someone upstream: "The SFD is defined to be in ASCII, and strings with characters outside this repertoire are normally encoded as UTF-7. You can see this in the handling of the name table, for example. However, the Copyright line isn't treated this way. Examination of sfd.c in the current (20090923) tarball shows that Copyright only has EOL-escaping performed, so it can only be ASCII. I think that correcting this would need the format definition changing to UTF-7 encode the Copyright line as well. The locale of the user shouldn't matter for reading and writing of these files."
(In reply to comment #3) > Ah ha. Another comment from someone upstream: > I think that correcting this would need the format definition changing to > UTF-7 encode the Copyright line as well. Thanks for info. So should we expect upstream for a patch?
If the format definition can be changed, it's much more reasonable to define everything as UTF-8 now
I have yet to hear any reaction from the main upstream developer. :) I'll voice our support for a UTF-8 here and see what happens. Feel free to create a patch for this if you are able. That would make it much easier for upstream to merge. :)
If I may summarise GW's three comments (upstream) on this matter, with my expansion in square brackets. 1. Font Info > Names > Copyright is a field that is supposed to only contain ASCII characters. The bug is actually that this field doesn't not restrict entered characters to ASCII. [This field becomes the Notice entry of the FontInfo dictionary in Type 1 fonts, and there is no way of specifying other character encodings for strings in these fonts.] 2. The encoding of SFD files will remain UTF-7. 3. If you are generating TTF or OTF fonts, you can put non ASCII characters in the copyright entries of the name table (Font Info > TTF Names). [Break the association by right-clicking the field and select "Detach from PostScript names". You can see this has been done if you load up the test font Caliban.sfd.] [I think that this is NOTABUG.]
Yeah, thanks Paul. I think that sums it up nicely.