Bug 572849 - (c) sign in copyright field was broken by fontforge
Summary: (c) sign in copyright field was broken by fontforge
Alias: None
Product: Fedora
Classification: Fedora
Component: fontforge
Version: 12
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Kevin Fenzi
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-03-12 07:47 UTC by Caius Chance
Modified: 2010-04-10 19:13 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-04-10 19:13:25 UTC
Type: ---

Attachments (Terms of Use)

Description Caius Chance 2010-03-12 07:47:26 UTC
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):

How reproducible:

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

Comment 1 Kevin Fenzi 2010-03-14 19:12:35 UTC
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.

Comment 2 Caius Chance 2010-03-15 00:42:46 UTC
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.

Comment 3 Kevin Fenzi 2010-03-15 15:14:25 UTC
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

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

Comment 4 Caius Chance 2010-03-16 00:22:42 UTC
(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?

Comment 5 Nicolas Mailhot 2010-03-16 08:58:15 UTC
If the format definition can be changed, it's much more reasonable to define everything as UTF-8 now

Comment 6 Kevin Fenzi 2010-03-16 22:59:50 UTC
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.  :)

Comment 7 Paul Flo Williams 2010-04-10 12:00:24 UTC
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.]

Comment 8 Kevin Fenzi 2010-04-10 19:13:25 UTC
Yeah, thanks Paul. I think that sums it up nicely.

Note You need to log in before you can comment on or make changes to this bug.