Jump to content
Typography.Guru
Rapha

FontForge – Unicode point duplicates issue

Recommended Posts

Rapha    0
Rapha

Trying to generate a self-created True Type font.

When validating I'm getting a bunch of characters with "There is another glyph in the font with this unicode code point". This happens after hinting, removing overlaps, correcting directions... It's the only thing that comes up when validating the font, everything else seems to be fine. Same when I directly generate TTF.

Is this a real issue I should be concerned about and if so how do I solve it?
The FF Validation messages don't have any details to them other than the name of character with the respective issue as quoted above in bold. By clicking on that list item it opens the respective problem character (for example LATIN CAPITAL LETTER E) but I don't see any reference as to where the (other) duplicate character sits and I don't understand what exactly I'm supposed to do. Am I supposed to just erase that character and hope I killed the right one of the two? Sorry in case I don't see/understand the obvious...

I tried to detach the respective characters. Tried to restart XQuartz and FontForge. But problems/messages persist.

I created the font from scratch. I use my own all Western European Character set (incl. all accents and some ligatures).

XQuartz 2.7.11 (xorg-server 1.18.4) FontForge 18:35 PDT, 2 April 2016 Mac mini (Late 2014), 3GHz i7, 16GB memo macOS Sierra 10.12.2

Any help is appreciated! Thank you!

Screen Shot 2017-01-23 at 5.01.49 PM.png

Share this post


Link to post
Share on other sites
Abraham Lee    8
Abraham Lee

Hi, Rapha! I've used FF pretty extensively. If you want to PM me your FF file, I'm happy to examine it to see if I can find anything.

Share this post


Link to post
Share on other sites
Rapha    0
Rapha

Hi Abraham,

Thank you for your reply!
While I appreciate your offer, for copyright reasons I don't feel comfortable sending my hard work around in the form of raw FF files. I hope you can understand that.
I was hoping that as a versed FF user you may have come across these error messages and may have an idea as to what they mean and how to solve these issues?
Any help/hint is appreciated at this point – I'm stuck!

Thank you very much!

Share this post


Link to post
Share on other sites
gluk    4
gluk

Hi, try

1. reencode font

[Encoding->Reencode->ISO 10461-1 (UNICODE, BMP)]

2. then scroll down and on end of font you will see (most probably) duplicated glyphs. Then you can remove slots

[Encoding->Detach&Remove Glyphs...]

3. again reencode...

Share this post


Link to post
Share on other sites
Rapha    0
Rapha

Thank you so much Gluk!


That means they are in fact duplicate/reduntant characters? 
If so this sounds like a good method. I do have duplicate codes towards the end – well, sort of.
They look identical but are named differently - more specifically: 
The actual Capital letter E for example is named 69 (0x45) U+0045 "E" Latin Capital Letter E, whereas the "duplicate" towards the end of the font is named 65317 (0xff25) U+FF25 "uniFF25" Fullwidth Latin Capital Letter E. Same with some of the other dubs. Not sure if that's what you meant?

Also, I did the reencoding as you suggested, detached and removed those mentioned "duplicates", reencodet again... but I still get the same error messages when validating or generating the TTF. In fact when I reencode these "dubs" at the end are coming straight back. If I generate the font without the dubs (just empty slots where they were) I still get the same dublicate messages. Mysterious!

I hope you don't mind me follow-up with two question:
1. Do these mentioned above "duplicates" at the end of the font have a specific purpose or are they literally just redundant duplicates?
2. Where do I go from here?

Thank you again for all your help and suggestions!
Best,
Rapha

 

 

Share this post


Link to post
Share on other sites
gluk    4
gluk

Hi,

it's misunderstanding. U+FF25 "uniFF25" Fullwidth Latin Capital Letter E is correct unicode point.

"on end of font" - I mean after U+FFFF "uniFFFF" Signature Mark ...

I had a similar situation after importing .fea file (OpenType features) [File->Merge Feature info...] into font with "incorrect" encoding.

Share this post


Link to post
Share on other sites
Rapha    0
Rapha

Thanks again, Gluk!

So it's a FF hiccup? What do I do from here? Is there a way to rename these "misunderstood" slots/glyphs? How did you solve it?

Share this post


Link to post
Share on other sites
gluk    4
gluk
Quote

So it's a FF hiccup?

Most probably yes...

Quote

What do I do from here?

If method above don't work, you can try:

  1.  reencode font [Encoding->Reencode->ISO 10461-1 (UNICODE, BMP)]

  2. copy outlines (width, anchors etc)  from glyph E, to temporary slot

  3. remove glyph E [Encoding->Detach&Remove Glyphs...]

  4. reencode font [Encoding->Reencode->ISO 10461-1 (UNICODE, BMP)]

  5. clean new slot for Glyph E and copy outlines from temporary slot to glyph E

  6. repeat for all duplicated characters...

  7. check OpenType features (kerning etc.)

 

 

Share this post


Link to post
Share on other sites
gluk    4
gluk

btw. thread from fontforge forum about this problem:

http://fontforge.10959.n7.nabble.com/correcting-errors-td11862.html

You can try manually edit sfd file in text editor, find text block

StartChar: E
Encoding: ...
...
EndChar

and remove it, or

  1. reencode font [Encoding->Glyph Order],
  2. search by unicode [Edit->Select->Select by Wildcard]
  3. remove one unnecessary glyph [Encoding->Detach&Remove Glyphs...]

a lot of work

Share this post


Link to post
Share on other sites
Rapha    0
Rapha

Hope I understand these instructions. I'll give that a shot.
Very helpful! Appreciate your time!

Best,
Rapha

Share this post


Link to post
Share on other sites
Rapha    0
Rapha

Hey Gluk,

I tried both your methods but can't seem to find the unnecessary glyphs/duplicates.
I then went with the method according to the link you provided as follows (for other people who might search for solving this issue here):
Reencode Unicode BMP. 
Select the glyph in font view. 
Copy it (very important, otherwise you will lose the glyph) 
Encoding / Detach and remove glyph. (this removes one of the glyphs) 
Reencode Unicode BMP (now you see the other glyph) 
Encoding / Detach and remove glyph. (removes the other glyph) 
Reencode Unicode BMP (now the slot is empty) 
Paste the glyph in the empty slot. 
Reencode Unicode BMP. 

I tried this for just one of the many slots (Capital E). The slot got never empty as suggested by the instructions above, even after doing this five times. Reencode always brought it right back.
But... interestingly enough, when I validate the font now all the duplicate error messages are gone. Instead I get a couple self-intersections (referenced accents) that weren't found during the previous evaluation.
Very odd! Doesn't make any sense, at least to me this sounds like a glitch. But hey, I'll take it.

I'll observe the behavior going forward and will report back here in case the issue comes back.
Fingers crossed...

Anyhow, thanks again for the generous help!
Rapha

Share this post


Link to post
Share on other sites
Rapha    0
Rapha

Btw. these mentioned self-intersections caused by referenced accents only show up when Element / Vlaidation / Validate but not when generating a TTF. As far as I understand this shouldn't cause problems in a True Type format. Correct?

 

Share this post


Link to post
Share on other sites
gluk    4
gluk

self-intersections in a True Type format could cause problems. As example screeenshot from Inkscape...

12.png

Share this post


Link to post
Share on other sites
Rapha    0
Rapha

Aw, I was told otherwise.
So I guess detach / remove overlaps.
Thanks for pointing that out!

Rapha

Share this post


Link to post
Share on other sites
Jason Pagura    0
Jason Pagura
On 1/31/2017 at 10:35 AM, Rapha said:

Aw, I was told otherwise.
So I guess detach / remove overlaps.
Thanks for pointing that out!

Rapha

Path direction is important in determining which intersecting parts of a glyph fill or drop out. The Element>Correct Direction feature usually will fix this, but when it doesn't do it as you think it should, you'll have to select the offending path and use Element>Reverse Direction

Share this post


Link to post
Share on other sites
Rapha    0
Rapha

Yup. I totally get that. I guess I was too used to .ai where it doesn't really matter.

Share this post


Link to post
Share on other sites
gluk    4
gluk
On 17.02.2017 at 2:42 AM, Jason Pagura said:

Path direction is important in determining which intersecting parts of a glyph fill or drop out. [..]

Problem is, it not always work. On my screenshot above (Inkscape0.48/debian) rectangle by "E" glyph is clockwise (and "E" path too) and by "D" counter clockwise.

Share this post


Link to post
Share on other sites
Abraham Lee    8
Abraham Lee
57 minutes ago, gluk said:

Problem is, it not always work. On my screenshot above (Inkscape0.48/debian) rectangle by "E" glyph is clockwise (and "E" path too) and by "D" counter clockwise.

Inkscape has its own algorithm for determining how to join to shapes and it's not obvious which "direction" they run. I would recommend simply creating the desired shapes in Inkscape (if needed), and then make the contours the correct direction in FF. In FF, contour direction is more obvious (there's a little arrow next to the first point in the contour).

The main idea is this (and there are times, as is said above, that you'll have to change direction manually when FF can't figure it out automatically): Whichever direction the contour is moving, the filled shape is on its "right". In other words, contours that "fill" should be clockwise directed and contours that "remove" should be counterclockwise. This directionality is necessary for many of FF's advanced contour/glyph operations.

So, the "E" glyph should have a single clockwise contour and the "D" glyph should have one clockwise contour (the outer one) and one counter-clockwise contour (the inner one).

@Ralf Herrmann @Riccardo Sartori Is this any different for other editors you've used?

Share this post


Link to post
Share on other sites
gluk    4
gluk

Thank You @Abraham Lee , but we talk about self-intersections in generated TTF:

On 31.01.2017 at 7:02 PM, Rapha said:

Btw. these mentioned self-intersections caused by referenced accents only show up when Element / Vlaidation / Validate but not when generating a TTF. As far as I understand this shouldn't cause problems in a True Type format. Correct?

 

In my reply I show Inkscape as example, that TTF with intersections could cause problems.

Share this post


Link to post
Share on other sites
Abraham Lee    8
Abraham Lee
1 minute ago, gluk said:

Thank You @Abraham Lee , but we talk about self-intersections in generated TTF:

In my reply I show Inkscape as example, that TTF with intersections could cause problems.

You are correct. My apologies. I meant to comment on this. A best practice (since it isn't all that uncommon to use multiple, overlapping shapes when constructing glyphs) is to remove all the overlapping regions at the time you actually generate the font file(s). That, of course, remedies situations like this.

Hopefully that can be taken just as good general advice since I've made the mistake before of leaving overlapping contours in final fonts and had this very thing happen (and have it show up on my own Resumé, of all places :-\ ).

Share this post


Link to post
Share on other sites

×