Font Forum

My unexpected results stemmed from having anti-aliasing enabled in Paint.NET when I created the source drawings. Apparently, the additional pixels gave rise to additional lines upon importing.

Well, oddly enough, I too was unable to exactly replicate my previous results as shown above. The 'Import Raster Image' screen captured is still showing the same 'Source Image' as it did previously but now, it is showing a very different 'Image used when generating contours;' which shows no contours...

In the past I have inported images without much trouble. However, today, I had some trouble importing an image of a bar chart I had created in Paint.net so, I had to create the charts within FC. I thought it would be useful to have a bar chart which showed "no signal" so, I created six charts in ord...

Erwin Denissen said: In this case FontCreator incorrectly identifies outline issues, as the bearings are fine. Could the outline issues found here be from the fact that the overall widths of the glyphs are much larger than the Advance Widths? For example: in the Semibold font, the smallest vowel si...

Yes, I did, thank you. In my case, the "offending" glyphs were all iterations of the Devanagari vowel sign I which stands to the left of a consonant, reaching over the consonant with various lengths. twelve indians.png As a combining glyph it has negative bearings on both the left and the right side...

More than a year later, I am tracking down the same problems. However, when I downloaded your file and opened it, there were no glyphs noted with "outline issues". When I ran font/validation, it came back with "123 glyphs have been (partially) fixed. 8 glyphs still have problems." and eight glyphs w...

The script will use the first accent that is available (provided that it is named correctly). That is what I suspected, thanks. The font I was working with had what looked like three different sizes of accent marks and only glyph numbers to tell them apart. That is why I had some 59 empty cells aft...

Just to illustrate how one might access the petite capital version of the German sharp S the way it is created by the UMPC script (SS), I made the section symbol act as the lowercase version of the German sharp s since the lowercase version of the German sharp s was already linked to the German shar...

Finally! Starting fresh after removing all of my little tweaks, the results are much closer to what I expect. With 7838, Germandbls, and 223, germandbls, in place prior to running the UMPC script we get the greatly anticipated SS glyph, germandbls.pcap, alongside the small sharp S, Germandbls.pcap. ...

I experimented on another font which, like mine, contained both upper and lower cases of the German Shsrp S. The UMPC script produced a new glyph, Germandbls.pcap. Trio.png When there was no Capital German Sharp S in the font, the script created a Germandbls.pcap from the germandbls (small German Sh...

Also, @ 50355 of ConpositeData, two s.pcaps are mapped to germandbls.pcap and the SS is, in fact , the uppercase form, not the lowercase.
I advocate for the name "smallsharps" for the lowercase form, "CapitalsharpS" for one form of the capital and "Germandbls" for the other form

You are killing my plans with this in CompositeData: <GlyphMapping>7838</GlyphMapping> <Member id="1"> <GlyphMapping>223</GlyphMapping> <UseMetrics>TRUE</UseMetrics> </Member> </Composite> This is why the lowercase sharp s winds up being used to create the Germandbls.pcap as illustrated in my images...

I am seeing doubles 😎 And, as is usual, my troubles are of my own making, Prior to running Unmapped Latin Petite Capitals.xml, I had created both the Latin small letter sharp s (@codepoint 223) and the Latin Capital letter Sharp S (@codepoint 7838) both of which I take to be replacements for the two...

Nevermind!!!
I discovered the Unmapped Latin Petite Capitals.xml
I see some possible kinks but this should work.
(I would have done the German sharp S a little differently for one thing)