[fontforge-users] Displaying all glyphs (including non-existent ones) in a character set?

[Nikolaus Waxweiler]

Hi list,
so this problem seems to be known, I want to check language support of
my font by displaying all glyphs of a given Adobe Latin 3/4/5 character
set. The groups feature doesn't work here, as it doesn't display
non-existant glyphs. But that's exactly what I want, so I can fill them
in. How?

Regards,
Nikolaus

[marty39]

I guess you've found it already, but I had the same problem. Groups doesn't
work, but Reencode does. Encoding, Reencode shows a list with a bunch of
"ISO-... (LatinX)" entries. I chose one at a time, and the glyphs I needed
were in the first 256 glyphs in the font view. Some were defined, some were
not supposed to be defined, and some were marked as assigned to a particular
glyph but hadn't been defined yet. All I had to do next was define the ones
in the last category.



--
View this message in context: http://fontforge.10959.n7.nabble.com/Displaying-all-glyphs-including-non-existent-ones-in-a-character-set-tp14916p14981.html
Sent from the User mailing list archive at Nabble.com.

[Nikolaus Waxweiler]

This is useful if encodings are what you want, I wanted a specific glyph
set (Adobe Latin 4) that defines its' own set and order within Unicode.
To be honest, I've written FontForge off here and instead try to help
improve Trufont :)

[Jason Pagura]

I recall that there is a way to write custom encoding files for FontForge,
though I couldn't tell you here without looking it up myself. Using that
feature you could add the Adobe glyph sets. I'm puzzled as to why they
aren't already included.

Post by Nikolaus Waxweiler
This is useful if encodings are what you want, I wanted a specific glyph
set (Adobe Latin 4) that defines its' own set and order within Unicode.
To be honest, I've written FontForge off here and instead try to help
improve Trufont :)
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
fontforge-users mailing list
https://lists.sourceforge.net/lists/listinfo/fontforge-users
http://fontforge.10959.n7.nabble.com/User-f8781.html

[Nikolaus Waxweiler]

If the function exists, I didn't find it. Oh well.

They probably aren't included because Adobe just recently started
putting out official lists:

https://adobe-type-tools.github.io/adobe-latin-charsets/
https://adobe-type-tools.github.io/adobe-cyrillic-charsets/
https://adobe-type-tools.github.io/adobe-greek-charsets/

There should be .enc files somewhere.

[m***@ansuz.sooke.bc.ca]

Post by Jason Pagura
I recall that there is a way to write custom encoding files for FontForge,

You're probably thinking of name lists, which specify the glyph names for
the slots in an encoding. Name lists are very close to what other systems
call "encodings" (in particular, the .enc files used for instance in TeX),
but "encodings" as FontForge uses that term are different. FontForge's
encodings specify which slots exist, and have consequences for file
formats. At this point in history it doesn't really make sense to use any
encoding of that kind for new fonts except Unicode. We already have
trouble when newbies attempt to use non-Unicode encodings for purposes
other than reading old legacy data, and I don't think it's a good idea to
add more. Better to remove some!

It sounds like what the original poster wanted wasn't really a new
"encoding" in the FontForge-specific technical sense, nor even exactly a
name list, but rather a convenient way to see a pre-specified subset of
Unicode as a kind of checklist of characters that ought to be in a new
font. One way to do that without changing FontForge might be to create a
template font with empty glyphs in the slots for the desired subset; then
users could view it with "Compact" turned on, and see all and only the
slots corresponding to the chosen subset. I think that'd serve the use
case without encouraging the use of a nonstandard "encoding."

Another idea, which would require some change to FontForge but ought not
to be a huge thing, would be to make namelists more visible, with a
setting in the UI to show all slots that have glyphs or are in a chosen
namelist. This would complement the existing settings of "Compact"
on (show only slots that have glyphs) and off (show all slots).

[Nikolaus Waxweiler]

Post by m***@ansuz.sooke.bc.ca
It sounds like what the original poster wanted wasn't really a new
"encoding" in the FontForge-specific technical sense, nor even exactly a
name list, but rather a convenient way to see a pre-specified subset of
Unicode as a kind of checklist of characters that ought to be in a new
font.

Exactly :)

Post by m***@ansuz.sooke.bc.ca
One way to do that without changing FontForge might be to create a
template font with empty glyphs in the slots for the desired subset; then
users could view it with "Compact" turned on, and see all and only the
slots corresponding to the chosen subset. I think that'd serve the use
case without encouraging the use of a nonstandard "encoding."

I'm also against abusing encodings here. Trufont displays only glyphs
that are in the font, not all possible code points of the selected
encoding. Users can define/import custom glyph sets in the settings.
When "Add glyph..."ing, users are given a text field where they can
paste glyph names or select a predefined glyph set. So a solution for my
problem would be to simply paste the glyph set definition or define it
globally and add that. Glyphs that are present already are skipped, new
ones are inserted as empty glyph slots. Tadaa, my desired outcome.

I actually really like this approach of showing what the font contains
instead of what the encoding allows. How ingrained is the latter model
in FontForge?

[Jason Pagura]

Ideally, switching glyph sets and compacting would be View options and
encodings would be set in the Font Info dialogue where it's less likely to
be messed with. It's something that was brought up years ago but never
settled. It would essentially mean duplicating the items of the Encodings
menu to the View menu (which, IMHO, has far too many items already); but
have them work in a non-destructive way—without altering the encoded glyph
order.

Adding a few data sets to the Encodings menu seems like it would be the
easiest way do do what you're asking from a programming perspective, but I
understand your reservations about using it in that way. It messes with
things that really shouldn't be messed with.

Post by Nikolaus Waxweiler

Post by m***@ansuz.sooke.bc.ca
It sounds like what the original poster wanted wasn't really a new
"encoding" in the FontForge-specific technical sense, nor even exactly a
name list, but rather a convenient way to see a pre-specified subset of
Unicode as a kind of checklist of characters that ought to be in a new
font.

Exactly :)

Post by m***@ansuz.sooke.bc.ca
One way to do that without changing FontForge might be to create a
template font with empty glyphs in the slots for the desired subset; then
users could view it with "Compact" turned on, and see all and only the
slots corresponding to the chosen subset. I think that'd serve the use
case without encouraging the use of a nonstandard "encoding."

I'm also against abusing encodings here. Trufont displays only glyphs
that are in the font, not all possible code points of the selected
encoding. Users can define/import custom glyph sets in the settings.
When "Add glyph..."ing, users are given a text field where they can
paste glyph names or select a predefined glyph set. So a solution for my
problem would be to simply paste the glyph set definition or define it
globally and add that. Glyphs that are present already are skipped, new
ones are inserted as empty glyph slots. Tadaa, my desired outcome.
I actually really like this approach of showing what the font contains
instead of what the encoding allows. How ingrained is the latter model
in FontForge?
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
fontforge-users mailing list
https://lists.sourceforge.net/lists/listinfo/fontforge-users
http://fontforge.10959.n7.nabble.com/User-f8781.html

[marty39]

Post by Jason Pagura
Ideally, switching glyph sets and compacting would be View options and
encodings would be set in the Font Info dialogue where it's less likely to
be messed with. It's something that was brought up years ago but never
settled. It would essentially mean duplicating the items of the Encodings
menu to the View menu (which, IMHO, has far too many items already); but
have them work in a non-destructive way—without altering the encoded glyph
order....

What does changing the encoding actually do? It clearly changes the
appearance of the Font View. But what does it change in the internals of the
generated font, and how does it affect the way the end users of the
generated font use it?



--
View this message in context: http://fontforge.10959.n7.nabble.com/Displaying-all-glyphs-including-non-existent-ones-in-a-character-set-tp14916p14994.html
Sent from the User mailing list archive at Nabble.com.

[Jason Pagura]

Encoding is the order of glyph cells in the generated font's database. If
you change the encoding, so will you also change the sequence of your
glyphs in your generated font. This can lead to surprising glyphs appearing
if the wrong encoding for your system is used. Therefore, before you
generate your font, be sure to untick the Compact attribute and Reencode to
Unicode (UTF-8 or 16), unless you are making the font for a specific legacy
system that doesn't support Unicode.

Post by marty39

Post by Jason Pagura
Ideally, switching glyph sets and compacting would be View options and
encodings would be set in the Font Info dialogue where it's less likely

to

Post by Jason Pagura
be messed with. It's something that was brought up years ago but never
settled. It would essentially mean duplicating the items of the Encodings
menu to the View menu (which, IMHO, has far too many items already); but
have them work in a non-destructive way—without altering the encoded

glyph

Post by Jason Pagura
order....

What does changing the encoding actually do? It clearly changes the
appearance of the Font View. But what does it change in the internals of the
generated font, and how does it affect the way the end users of the
generated font use it?
--
http://fontforge.10959.n7.nabble.com/Displaying-all-glyphs-including-non-existent-ones-in-a-character-set-tp14916p14994.html
Sent from the User mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
fontforge-users mailing list
https://lists.sourceforge.net/lists/listinfo/fontforge-users
http://fontforge.10959.n7.nabble.com/User-f8781.html

[m***@ansuz.sooke.bc.ca]

Post by Jason Pagura
Encoding is the order of glyph cells in the generated font's database. If
you change the encoding, so will you also change the sequence of your glyphs
in your generated font. This can lead to surprising glyphs appearing if the

Although that's true in general, I'm not sure it's true in all cases. At
the very least, there is special handling of glyphs like ".notdef", which
appears at the start of the file (in some file formats) despite being an
unencoded glyph.

I would rather say that the font's "encoding" specifies a mapping between
characters (which are abstract concepts) and a sequence of numbers inside
FontForge, and that sequence of numbers usually has consequences for how
FontForge will translate data to meet the requirements of a font file
format, when writing a font file.

One consequence of the "encoding" is that it specifies how many glyph
slots you get - but you can also always add extra "unencoded" slots.

When the "encoding" setting is not Unicode, FontForge also keeps track of
an optional Unicode number for each glyph slot, and that also affects the
translations applied when generating a font file.

The exact consequences of "encoding" do not seem to be documented, but
they certainly depend both on which encoding we're talking about and on
the font file format being generated. My impression is that the settings
that make most sense are Unicode (either BMP-only or "Full"), which stores
glyphs in order by their standard code point, and "Custom" (which makes
very few restrictions and just stores glyphs by their slot number,
assuming the user knows what the user wants).

Post by Jason Pagura
wrong encoding for your system is used. Therefore, before you generate your
font, be sure to untick the Compact attribute and Reencode to Unicode (UTF-8

"Compact" *ought* to affect display only, and I wouldn't recommend turning
it off in a font that uses multiple planes of Unicode, because without it,
finding desired slots in the GUI is basically impossible. I'm aware that
"Compact" does affect some things other than display, and I think that
should be treated as a bug and fixed. UTF-8 and UTF-16 are not choices
for reencoding (and shouldn't be, since they don't describe mappings
between characters and numbers, but between numbers and byte sequences);
the available Unicode choices are "BMP" (meaning only code points U+0000
to U+FFFF) and "Full" (meaning all the code points in Unicode, which go up
to U+10FFFF).

[marty39]

Post by Jason Pagura
Encoding is the order of glyph cells in the generated font's database. If
you change the encoding, so will you also change the sequence of your
glyphs in your generated font....

I don't understand that.

When I open a 1992 or 1993 font in FontForge, it shows Unicode BMP encoding,
but when I reencode to "glyph order" I see a different layout, with .notdef
in the first slot. When I encode a font as KOI8-R, generate a TrueType font,
and open the font in FontForge, the encoding is shown as Unicode BMP, and
reencoding in glyph order shows .notdef in the first slot, with no
indication that the font was generated with KOI8-R encoding.

If encoding is the order of glyphs in the generated font, why does encoding
in "glyph order" in FontForge show a layout that's different from any
recognized encoding? And why can't FontForge open a font with the font's own
encoding?




--
View this message in context: http://fontforge.10959.n7.nabble.com/Displaying-all-glyphs-including-non-existent-ones-in-a-character-set-tp14916p14997.html
Sent from the User mailing list archive at Nabble.com.

[Jason Pagura]

I defer to those who have more expertise on this topic than I do. I don't
claim to know all the details intimately.
It has been my experience that, when generating a font in FontForge, having
the Compact attribute on has caused problems for me; faulty keymappings and
such. It's hard to recall the exact nature since taking this precaution of
unchecking Compact before generating has become so habitual for me.

Post by marty39

Post by Jason Pagura
Encoding is the order of glyph cells in the generated font's database. If
you change the encoding, so will you also change the sequence of your
glyphs in your generated font....

I don't understand that.
When I open a 1992 or 1993 font in FontForge, it shows Unicode BMP encoding,
but when I reencode to "glyph order" I see a different layout, with .notdef
in the first slot. When I encode a font as KOI8-R, generate a TrueType font,
and open the font in FontForge, the encoding is shown as Unicode BMP, and
reencoding in glyph order shows .notdef in the first slot, with no
indication that the font was generated with KOI8-R encoding.
If encoding is the order of glyphs in the generated font, why does encoding
in "glyph order" in FontForge show a layout that's different from any
recognized encoding? And why can't FontForge open a font with the font's own
encoding?
--
http://fontforge.10959.n7.nabble.com/Displaying-all-glyphs-including-non-existent-ones-in-a-character-set-tp14916p14997.html
Sent from the User mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
fontforge-users mailing list
https://lists.sourceforge.net/lists/listinfo/fontforge-users
http://fontforge.10959.n7.nabble.com/User-f8781.html

[marty39]

For reference: I was not aware that the Adobe Latin character sets are
different from the ISO Latin character sets. Useful information.



--
View this message in context: http://fontforge.10959.n7.nabble.com/Displaying-all-glyphs-including-non-existent-ones-in-a-character-set-tp14916p14989.html
Sent from the User mailing list archive at Nabble.com.

[Nikolaus Waxweiler]

I like them, they are grouped mostly by language coverage instead of
Unicode ranges.

https://github.com/adobe-type-tools/adobe-latin-charsets
https://github.com/adobe-type-tools/adobe-cyrillic-charsets
https://github.com/adobe-type-tools/adobe-greek-charsets