Use GNU Unifont at 16px #1031

Open
davelab6 opened this Issue Dec 6, 2013 · 41 comments

Projects

None yet

6 participants

@davelab6
Member
davelab6 commented Dec 6, 2013

Paul Hardy of GNU Unifont fame writes,

The open area inside the rectangle where Fontforge draws sample glyphs is exactly 16 pixels tall, the same height as Unifont glyphs.

Is there any chance of tweaking Fontforge for the next release so that if Unifont is installed the Fotnforge sample glyphs are rendered as 16 pixels tall, and either 8 or 16 pixels wide? The glyphs would look razor-sharp then so their quality would be greatly improved.

DONE :)

Most of the glyphs except some CJK have a margin of blank pixels on top and bottom, so most wouldn't touch the rectangle top and bottom boundaries. You can scroll through the CJK ideographs in Fontforge to get a better idea of the blurring consequences.

Installing the TrueType version of Unifont, then using Fontforge to look at the PCF (or BDF) version gives the best indication, because with a bitmap font Fontforge will give an anti-aliased, pixel-by-pixel rendering.

Along those lines, would you like me to make an SBIT version of Unifont part of future TrueTupe packages for GNU/Linux, along with the non-SBIT version? I'd have to name it something like "Unifont_SBIT". Then Fontforge could use that font if it's installed; if not, it could use "Unifont" if that's installed, and if not then fall back to some system font.

With Unifont being 16 pixels tall, and the rectangular sample box having 16 rows for display, it does seem a match made in heaven. :-)

@davelab6 davelab6 was assigned Dec 6, 2013
@mozbugbox
Contributor

It seems that the sample font size as well as the glyph label are controlled by the fv_fontsize, default to 11. Which can be set through File->X Resource Editor->Font View->Font Size.

@davelab6
Member
davelab6 commented Dec 8, 2013

Right. Here it is today:

screen shot 2013-12-07 at 14 17 54

Here it is with a one byte change here from 10 to 16:

screen shot 2013-12-07 at 14 18 37

Look good?

@paulhardy

Thank you. Setting the Font Size to "12" renders the glyphs pixel-perfect, aspect-ratio wise. There are two remaining problems with this:

  1. The rendered sample glyphs are two pixels higher than they should be, so that tall glyphs bleed into the row above (see attachment).

  2. This is a manual step; given that Unifont is the default, it would be nice to set the point size for the sample glyphs to 12 pt (as an alternative to 16 px) automatically if Unifont is the sample font. Also, changing the font size has no effect on an open window; it is necessary to open a new font window within the current Fontforge session. Setting the Unifont sample font size to 12 pt would avoid both of these manual steps.

I'm attaching a screen capture of Fontforge running with unifont.ttf installed, using that as a sample font set to 12 pt, and viewing unifont.pcf.gz. If you look at the glyph that is highlighted in yellow (U+0F15), see how sharp the two one-pixel points near the top of the glyph appear in the sample rectangle. Also see how the glyph highlighted in yellow touches the very bottom of its window with room for two extra rows of pixels on top--that is the correct placement; and see how the sample glyph above is two pixel rows higher, causing its top two rows to bleed above its rectangle.

The effect of this bleeding is more evident with combining characters along the bottom row.

unifontmedium

@davelab6
Member
davelab6 commented Dec 8, 2013

68c3390 :)

@paulhardy

Dave,

We posted almost simultaneously! Your sample glyphs are anti-aliased. I like the ones in my sample above better because there is no anti-aliasing--they're very crisp.

@davelab6
Member
davelab6 commented Dec 8, 2013

see how the glyph highlighted in yellow touches the very bottom of its window with room for two extra rows of pixels on top--that is the correct placement; and see how the sample glyph above is two pixel rows higher, causing its top two rows to bleed above its rectangle.

Yep. Its a bug, probably a 1-2 line change somewhere in the Font View code, or maybe GDraw, the unique X Toolkit used by FontForge.

@davelab6
Member
davelab6 commented Dec 8, 2013

Along those lines, would you like me to make an SBIT version of Unifont part of future TrueTupe packages for GNU/Linux, along with the non-SBIT version?

Yes, let's try to include a SBIT version in FF :)

@adrientetar
Member

What's the state of this issue? Also, why is it tagged as a bug?

@ilyaza
ilyaza commented Jul 10, 2014

Also, there is now a de-rasterized Unifont (http://ilyaz.org/fonts) with which such micro-tuning may be not needed anymore.

@paulhardy

Adrien,

Fontforge uses Unifont as a font of last resort to display glyphs if it is
installed on a system. I created an SBIT font just for Fontforge. Its
glyphs are 16 pixels tall. Fontforge has a blank area that is 16 pixels
tall where it displays sample glyphs for code points (above the area where
a font's glyph would appear). However, Unifont sample glyph positions are
off vertically by 2 pixels.

Showing them at their native font size of 16 pixels tall will allow them to
appear razor-sharp in Fontforge, with no blurriness from anti-aliasing. At
the small size they are displayed, having a one-to-one correspondence
between pixels in the SBIT font and pixels on the screen will make the
sample glyphs much more legible.

Also, I haven't looked into this yet, but Fonforge does not display the
Unifont "upper" sample SBIT font that my latest package creates. I don't
know if that is a bug in Fontforge not displaying SBIT glyphs above
Unicode's BMP or if it is something wrong I did in building the
upper-planes SBIT font.

Paul

@paulhardy

Ilya,

I was not aware of your doing anything with Unifont. Thank you for your
interest in it. I would recommend that Fontforge look for the versions
distributed through http://ftp.gnu.org/gnu/unifont/ and discussed at
https://savannah.gnu.org/projects/unifont/ though, because those links will
always point to the latest official releases. The latest versions provide
coverage for the Unicode 7.0 Basic Multilingual Plane and beyond, whereas
the version on your site is an older version.

Letting the sample glyphs appear pixel-perfect on a standard screen gives
optimal rendering. I'd like to look at the scripts you have created in the
future to create TrueType outputs though.

If you do redistribute Unifont, please make sure to include the license
information with the distribution, in keeping with the GPL.

Thanks,

Paul

@davelab6
Member

Sorry, I see this was written me to offlist by Paul Hardy in December - I
didn't action this, and hope someone else can:

Here's an SBIT version of Unifont that you can use to experiment:

http://unifoundry.com/pub/unifont-6.3.20131020/font-builds/unifontcircles-sbit-6.3.20131020.ttf.gz

That version includes combining circles; it's the only version that does.
They are properly centered depending on whether the associated glyph is
single- or double-width. Because it has combining circles, I want this
font to have a name other than "unifont" to avoid conflicts. The best idea
that's come to mind is "unifont_sample", with the idea that the glyphs can
be used to form a sample book or similar graphic output.

I realize the font having combining circles is a complication in that if
you're using that version, ideally you'll have to disable Fontforge's
displaying its own combining circles. If you can do that though, I'd like
to include "unifont_sample" as part of the standard Unifont build and
install it alongside the ordinary unifont.ttf file.

Don't use the above version as a final copy though. It's close to what
will be in my next release, but not 100%. Tomorrow I'm going to get
together with someone Armenian to review the whole Armenian alphabet.
Someone told me he thought there were problems so I'm going to verify it
with someone native to Armenia. I'm also going to review the CJK Radicals
Supplement block (U+2E80..U+2EFF); I've seen some discrepancies there. I'm
going to have an expert review my work on the CJK ideographs when I'm done.

I should then be able to put together a new build next weekend, or the
weekend after that at the latest. If the CJK ideograph modifications
aren't done by then, I won't hold up the next release for it.

Adding the "unifont_sample" font should just take adding a sed script and
similar code to an existing Makefile so it builds automatically along with
everything else. At least I hope so...

@ilyaza
ilyaza commented Jul 11, 2014
Ilya, I was not aware of your doing anything with Unifont.

Paul, I sent email to you (and Roman) on March 31, 2013. I was wondering what happened to it…

I'd like to look at the scripts you have created in the future to create TrueType outputs though.

Have you? In addition to scripts, I also fix the “unacceptable” glyphs. (The build environment is included in every distribution.)

the version on your site is an older version

First, a lot of thanks for keeping this font up to date!
Second, I would not use such words to describe “my version”. It is based on an older version of Unifont rasters. But since the usability of these rasters is severely limited (comparing to what I distribute), it is kinda living on a different plane ;-). (I know about 7.0 release; but since a re-build takes many hours on CPU, and many more hours of my time, I want to synchronize it with other update [probably, for the next release, a fix of glyphs for big operators, and a switch from cubic splines to spiro splines].)

make sure to include the license

Thanks for reminding me. Without reminders I would procrastinate more and more (even knowing that this is not acceptable).

@ilyaza
ilyaza commented Jul 12, 2014
make sure to include the license

Is the current version satisfactory? (I also fixed the obsoleted parts —  now of Katakana, Bopomoto and Jamo only 1 character is missing —  it stops .notdef from working in PUA [go figure!] in Windows’ console.)

@paulhardy

On Fri, Jul 11, 2014 at 9:25 AM, Dave Crossland notifications@github.com
wrote:

Sorry, I see this was written me to offlist by Paul Hardy in December - I
didn't action this, and hope someone else can:

...

Here is the latest version of the Plane 0 Unifont Sample (SBIT font, as per
the request of Dave and other Fontforge users) and the upper-planes Unifont
Sample (also an SBIT font), with md5 sums:

http://unifoundry.com/pub/unifont-7.0.03/font-builds/unifont_sample-7.0.03.ttf

http://unifoundry.com/pub/unifont-7.0.03/font-builds/unifont_sample-7.0.03.ttf.md5

http://unifoundry.com/pub/unifont-7.0.03/font-builds/unifont_upper_sample-7.0.03.ttf

http://unifoundry.com/pub/unifont-7.0.03/font-builds/unifont_upper_sample-7.0.03.ttf.md5

And for good measure, a GPG signature file for the Plane 0 TTF Sample font,
because it is there:

http://unifoundry.com/pub/unifont-7.0.03/font-builds/unifont_sample-7.0.03.ttf.sig

The Unifont Upper Sample SBIT font doesn't display in the copy of Fontforge
20120731 that I am running on Debian GNU/Linux, with "libfontforge
20120731-ML". I haven't had time yet to see if that is a problem with
Fontforge displaying SBIT glyphs beyond Plane 0 or if it is a problem with
the Unicode Upper Sample SBIT font itself. As a result, I hadn't put that
font online previously. However, because there is renewed interest in the
SBIT version of Unifont, I've just uploaded it.

Let me know if you would like any further information.

Have fun!

Paul

@paulhardy

Ilya,

On Fri, Jul 11, 2014 at 3:05 PM, ilyaza notifications@github.com wrote:

Ilya, I was not aware of your doing anything with Unifont.

Paul, I sent email to you (and Roman) on March 31, 2013. I was wondering
what happened to it…

Sorry, my mail box was full then and I did lose some emails that were sent
to me at that time. So I never saw the email you sent to me.

I'd like to look at the scripts you have created in the future to create
TrueType outputs though.

Have you? In addition to scripts, I also fix the “unacceptable” glyphs.
(The build environment is included in every distribution.)

I haven't looked at your scripts yet, but I will.

the version on your site is an older version

First, a lot of thanks for keeping this font up to date!

You're welcome. I try, with the help of other volunteers!

Paul

@paulhardy

Ilya,

On Sat, Jul 12, 2014 at 12:51 AM, ilyaza notifications@github.com wrote:

make sure to include the license

Is the current version satisfactory? (I also fixed the obsoleted parts —
now of Katakana, Bopomoto and Jamo only 1 character is missing — it stops
.notdef from working in PUA [go figure!] in Windows’ console.)

The license that applies to all the work for GNU Unifont, including the
source code, is here:

http://unifoundry.com/LICENSE.txt

In a nutshell, it is GPLv2+ with GNU's Font Embedding Exception.

Can you please explain the ".notdef" problem on Windows? I am planning
another release around the beginning of September, which will include more
Supplemental Multilingual Plane glyphs. If there is some problem with the
font on Windows I can try to fix it in that release.

Thank you,

Paul

@paulhardy

Ilya,

On Sat, Jul 12, 2014 at 4:54 PM, Paul Hardy unifoundry@gmail.com wrote:

Ilya,

On Sat, Jul 12, 2014 at 12:51 AM, ilyaza notifications@github.com wrote:

... (I also fixed the obsoleted parts — now of Katakana, Bopomoto and
Jamo only 1 character is missing — it stops .notdef from working in PUA
[go figure!] in Windows’ console.)

Can you please explain the ".notdef" problem on Windows? I am planning
another release around the beginning of September, which will include more
Supplemental Multilingual Plane glyphs. If there is some problem with the
font on Windows I can try to fix it in that release.

For Unicode bugs, it would be best to report them on Savannah so everyone
can see them. Look at the "Bugs" section on this web page:

https://savannah.gnu.org/projects/unifont/

Thank you,

Paul

@ilyaza
ilyaza commented Jul 13, 2014
Can you please explain the ".notdef" problem on Windows?

Since your fonts do not have .notdef, there is no such problem.

If there is some problem with the font on Windows[…]

Basically, you do not have a well-formed TrueType font. Sorry, but with your version of a TT build, IMO it does not make any sense to discuss whether it works on Windows.

@paulhardy

Ilya,

On Sun, Jul 13, 2014 at 12:05 PM, ilyaza notifications@github.com wrote:

Can you please explain the ".notdef" problem on Windows?

Since your fonts do not have .notdef, there is no such problem.

The BDF font defines "DEFAULT_CHAR 65533". The code that converts a BDF
font to a TrueType or SBIT font is in "font/ttfsrc/Makefile". If there is
something additional the TrueType conversion should be making, let me know.

If there is some problem with the font on Windows[…]

Basically, you do not have a well-formed TrueType font. Sorry, but with
your version of a TT build, IMO it does not make any sense to discuss
whether it works on Windows.

Windows 7 and Windows 8 users have told me that the latest builds of
Unifont work on their systems. I am only aware of one way in which Unifont
does not strictly conform to the TrueType standard. That is discussed in
this bug report:

https://savannah.gnu.org/support/?108441

Unifont has more than 32k glyphs in one font; it has up to 64k. That is a
violation of the TrueType standard in a strict interpretation. However, I
am pursuing getting that artificial restriction relaxed. Chrome, Chromium,
and Firefox now permit fonts with up to 64k glyphs as a result of that
effort. Google had black-listed Unifont and Wen Quan Yi in Chromium
because both of those fonts had over 32k glyphs, but that blacklisting of
both Unifont and Wen Quan Yi also has been lifted as part of this effort to
allow up to 64k glyphs per font.

If there is another issue with Unifont and TrueType, please file a bug
report against Unifont on Savannah. Please check the latest version before
doing that though. The TrueType conversion is done in Fontforge, so if you
have Fontforge expertise and can recommend changes in the BDF conversion
that also would be appreciated.

Paul

@ilyaza
ilyaza commented Jul 15, 2014

I wrote:

Can you please explain the ".notdef" problem on Windows?
Since your fonts do not have .notdef, there is no such problem

Actually, FontForge auto-inserts something similar into a file, so my denial may be misleaded. So:

  • Character inserted by FontForge is (AFAIK) not called .notdef.
  • Character inserted by FontForge is of wrong width.
  • Character inserted by FontForge is of little use anyway, since your build of UniFont is not having undefined slots in U+0000..U+FFFF.
  • On Windows’ console, if a font defines U+0000 (or U+0001), this (apparently) is used instead of .notdef.
  • On Windows’ console, if a (non-Asian?) font defines U+30FB, this (apparently) is used instead of .notdef for undefined characters in PUA.

The first problem may be construed as a FontForge bug (if valid; I just inspected output of ttfdump, and I do not know exactly where to look). The second one probably is not, since Unifont is not a monospaced font.

@ilyaza
ilyaza commented Jul 15, 2014

Paul,

The BDF font defines "DEFAULT_CHAR 65533". The code that converts a BDF font to a TrueType or SBIT font is in "font/ttfsrc/Makefile".

AFAIK, there is no conversion from BDF to TrueType whatsoever. TrueType font is built from .hex file.

@ilyaza
ilyaza commented Jul 15, 2014

Paul,

Windows 7 and Windows 8 users have told me that the latest builds of Unifont work on their systems.

[In my experience, users saying that something “works” carries zero information content. Until I check my stuff myself, bugs just remain there.]

Myself, when I was trying your build of Unifont (about 2 years ago), i was forced to uninstall it the next day — it malforminess broke character display in many applications. (The principal reason is that it pretends it supports all the characters in the range U+0000..U+FFFF.)

The BDF font defines "DEFAULT_CHAR 65533".
@ilyaza
ilyaza commented Jul 15, 2014

[continuing, sorry for a break]

Looking in NamesList.txt,

FFFD    REPLACEMENT CHARACTER
    * used to replace an incoming character whose value is unknown or unrepresentable in Unicode

Why do you think it is appropriate for .notdef? The main usage of .notdef is to visualize valid Unicode characters not present in the font.

@paulhardy

Ilya,

On Mon, Jul 14, 2014 at 7:27 PM, ilyaza notifications@github.com wrote:

I wrote:

Can you please explain the ".notdef" problem on Windows?

Since your fonts do not have .notdef, there is no such problem

Actually, FontForge auto-inserts something similar into a file, so my
denial may be misleaded. So:

  • Character inserted by FontForge is (AFAIK) not called .notdef.
  • Character inserted by FontForge is of wrong width.
  • Character inserted by FontForge is of little use anyway, since your
    build of UniFont is not having undefined slots in U+0000..U+FFFF.

There are undefined slots in the PUA, so if no other font provides those
glyphs then .notdef would come into play there. This is not the case with
the Unifont version from two years ago.

  • On Windows’ console, if a font defines U+0000 (or U+0001), this
    (apparently) is used instead of .notdef.

So if those are present in a font then the "wrong-width" Fontforge .notdef
glyph will not appear?

  • On Windows’ console, if a (non-Asian?) font defines U+30FB, this
    (apparently) is used instead of .notdef for undefined characters in
    PUA.

About that I can do nothing; it is a Katakana glyph that I can't remove.

The first problem may be construed as a FontForge bug (if valid; I just
inspected output of ttfdump, and I do not know exactly where to look).
The second one probably is not, since Unifont is not a monospaced font.

What is it that makes the latest release of Unifont a malformed TrueType
font? Where does it violate the TrueType spec apart from having over 32k
glyphs?

Paul

@ilyaza
ilyaza commented Jul 16, 2014
There are undefined slots in the PUA

Forgot about those (and surrogates). OK, so the .notdef-not-working issue is relevant.

This is not the case with the Unifont version from two years ago.

The problem caused by UniFont were not PUA-specific (nor Windows-specific).

On Windows’ console, if a font defines U+0000 (or U+0001), this (apparently) is used instead of .notdef.

So if those are present in a font then the "wrong-width" Fontforge .notdef glyph will not appear?

Irrelevant, since your build of Unifont is not compatible with Windows’ console.

  • On Windows’ console, if a (non-Asian?) font defines U+30FB, this (apparently) is used instead of .notdef for undefined characters in PUA.

About that I can do nothing; it is a Katakana glyph that I can't remove.

Of course you can. Anyway, you need to delete Han and Hangul for compatibility with the console.

What is it that makes the latest release of Unifont a malformed TrueType font?

Three main issues are:

  • .notdef of wrong width (conjecturally; I cannot test your build, since I expect it would play havoc on my computer — so it is possible .notdef would not work at all);
  • Unifont assumes it is the smartest guy in the block, so refuses to share the playground with other fonts (remove pseudo-glyphs for codepoints with missing glyphs).
  • Wrong names of glyphs: use uniABCD instead of ABCD, and uABCDEF instead of ABCDEF.

(These are the issues for GUI applications; making Unifont useful with the Windows’ console is another can of worms — it took me almost a year to get to the current state with my build.)

@paulhardy

Ilya,

On Tue, Jul 15, 2014 at 8:37 PM, ilyaza notifications@github.com wrote:

There are undefined slots in the PUA

Forgot about those (and surrogates). OK, so the .notdef-not-working issue
is relevant.

This is not the case with the Unifont version from two years ago.

The problem caused by UniFont were not PUA-specific (nor Windows-specific).

On Windows’ console, if a font defines U+0000 (or U+0001), this
(apparently) is used instead of .notdef.

So if those are present in a font then the "wrong-width" Fontforge .notdef
glyph will not appear?

Irrelevant, since your build of Unifont is not compatible with Windows’
console.

  • On Windows’ console, if a (non-Asian?) font defines U+30FB, this
    (apparently) is used instead of .notdef for undefined characters in
    PUA.

    About that I can do nothing; it is a Katakana glyph that I can't remove.

Of course you can. Anyway, you need to delete Han and Hangul for
compatibility with the console.

I was not aware of Windows not wanting Asian glyphs in a console font in
order to properly render Western glyphs. You are the first person to bring
up using Unifont as a Windows console font. Of course if I did that, then
Unifont would not be a pan-Unicode font, so I would have to create a custom
version for Windows' console mode.

The point of Unifont is that it would be a pan-Unicode font. Not
necessarily a pretty one, just a simple bitmapped font with a goal of
providing something meaningful for each assigned Unicode code point.

What is it that makes the latest release of Unifont a malformed TrueType
font?

Two main issues are:

  • .notdef of wrong width (conjecturally; I cannot test your build,
    since I expect it would play havoc on my computer — so it is possible
    .notdef would not work at all);

I am not a Fontforge expert. If you can provide Fontforge commands to
define .notdef as some existing glyph, please do.

  • Unifont assumes it is the smartest guy in the block, so refuses to
    share the playground with other fonts (remove pseudo-glyphs for codepoints
    with missing glyphs).

There are no pseudo-glyphs for missing glyphs, because there are no
missing glyphs (as of Unicode 7.0). Unifont just has only four- or
six-digit hexadecimal glyphs for code points that are unassigned in The
Unicode Standard (except in the PUA). Right now in all of the Unicode 7.0
Basic Multilingual Plane, there are exactly 1998 such four-digit
hexadecimal glyphs to represent unassigned code points in the entire 64k
code point space (not counting the PUA). No such hexadecimal glyphs exist
in Unifont for code points that Unicode defines.

I also have a file of 6400 four-digit hexadecimal glyphs for the PUA, in
font/plane00/pua.hex, but those glyphs are not included in the default
Unifont build. Someone would have to create a custom build to include them.

While completing Unifont coverage for Unicode 5.1, I had to deal with
Unifont having many holes in scripts. I could not easily distinguish
between a code point with a missing glyph and a code point that was
unassigned while trying to determine how much remained to do. So I created
a file of filler glyphs for all unassigned BMP code points. Then I could
easily tell where there was still work to be done.

Later I wrote a program to generate four- and six-digit hexadecimal glyphs.

I have also made it easy to build the font without them if someone is so
inclined. On a GNU/Linux, cygwin, etc. command line, just type

make BUILDFONT=1 UNASSIGNED=""

That is described in the documentation included in the source code.

The font does conform to The Unicode Standard though. For Unifont 5.1, I
used recommendations of The Unicode Standard for filler glyphs and PUA
glyphs. In Unifont 6.x and now 7.0, I removed all PUA glyphs, but provide
some ConScript Unicode Registry PUA glyphs in separate font files. Unicode
allows a font to contain glyphs for unassigned code points exactly for the
reason you mention: so they will be rendered with metrics that are similar
to other glyphs in the font. That I verified with The Unicode Consortium
in 2008, and verified that this had not changed in 2013.

The only folks who would probably be delving into the realm of unassigned
code points are Fontforge users. Many Windows users have told me they were
happy with the hexadecimal glyphs, as being better than the default empty
box that Windows provides for an unassigned code point.

For GNU/Linux Fontforge users, I sent out a poll request to the Fontforge
Users mailing list. I decided to go with whatever the majority who
responded wanted. You can see the results here:

http://unifoundry.com/poll_unassigned/index.php

The majority of people who voted also wanted the Unifont hexadecimal glyphs
for unassigned code points--the same as the Windows Fontforge users who
contacted me.

So what the font contains is what the majority of Fontforge users on both
Windows and GNU/Linux have requested of me.

(These are the issues for GUI applications; making Unifont useful with the
Windows’ console is another can of worms — it took me almost a year to get
to the current state with my build.)

I did not have a goal of making something that could serve as a Windows
console font for non-Asian scripts; you are the first person to bring up
such an option to me.


Reply to this email directly or view it on GitHub
#1031 (comment)
.

Paul

@ilyaza
ilyaza commented Jul 16, 2014

About that I can do nothing; it is a Katakana glyph that I can't remove.

Of course you can. Anyway, you need to delete Han and Hangul for compatibility with the console.

I was not aware of Windows not wanting Asian glyphs in a console font in order to properly render Western glyphs.

I have not said this — and I have no clue whether it is true or not.

So when you have Asian glyphs drawn in 16×8 bitmap, one may need to revisit this point. (Recall: Windows’ console requires a monospace font.)

@ilyaza
ilyaza commented Jul 16, 2014

Two main issues are:

Aha! it looks like you read during those 2 minutes before I added the third issue!

  • .notdef' of wrong width (conjecturally; I cannot test your build, since I expect it would play havoc on my computer — so it is possible.notdef` would not work at all);

I am not a Fontforge expert. If you can provide Fontforge commands to
define .notdef as some existing glyph, please do.

Somehow I do not follow… Paul, you DO realize that all the issues we are discussing ARE fixed in my build — which is publicly available?

@ilyaza
ilyaza commented Jul 16, 2014
  • Unifont assumes it is the smartest guy in the block, so refuses to share the playground with ther fonts (remove pseudo-glyphs for codepoints with missing glyphs).

There are no pseudo-glyphs for missing glyphs, because there are nomissing glyphs (as of Unicode 7.0).

Paul, as you say yourself, there are thousands of missing glyphs (outside of PUA and surrogates area). And Unicode version has nothing to do with this — it is very simple: if you do not know how to draw a glyph, leave this codepoint undefined in the font. TrueType fonts are used (or may be used) in environments where multiple fonts cooperate to render a string; the requirement above is CRUCIAL in making this goal achievable.

I⁾m afraid this still is not enough to reach you… OK, two usage scenarios:

  • I view a document containing Ꭓ U+A7B3 LATIN CAPITAL LETTER CHI; suppose I have a font which has this letter. Will I be able to see it? If I did not install Unifont — it is not a problem (on appropriately capable architectures, e.g., on Linux, or on older — or tuned up — Firefoxes on Windows). If I install my build of Unifont — it is not a problem. But with your build of TrueType Unifont, it becomes a Russian roulette — maybe I will see it, maybe I will see a black square with some scribbles on it.
  • I install your version of Unifont. 10 years later, I view a document — and half of glyphs are black squares with some scribbles. I contact the author of the document — he says that on older computers, it is enough to install the latest version of Symbola, and the document will show. But I have the latest version of Symbola! I reinstall, I reboot, I uninstall and install Symbola again and again — to no avail. What should I do next?

Did I get through now that the version of Unicode is absolutely irrelevant in this discussion?

@ilyaza
ilyaza commented Jul 16, 2014

just type
make BUILDFONT=1 UNASSIGNED=""

So do it when you build the TrueType version. (I do it differently for my build.)

@ilyaza
ilyaza commented Jul 16, 2014

I decided to go with whatever the majority who responded wanted.

Paul, people have no clue. Your users have no clue (if you combine clue by averaging). The majority has yet less clue.

It is your responsibility as of a designer to anticipate and counteract the problems your users cannot (on average) anticipate themselves. Delegating this responsibility to users is an ostrich policy. So the designers should invent a method of combining the total clue of their users to help them in these goals.

(And, in my experience, for a nice piece of software, the combined clue of the users would greatly overshoot the clue of the designer. One should just combine them correctly — and voting is not a solution!)

@ilyaza
ilyaza commented Jul 16, 2014

with the hexadecimal glyphs, as being better than the default empty box that Windows provides for an unassigned code point.

Paul, this “the empty box” is not “what Windows provides”. It is just .notdef of your font.

@ilyaza
ilyaza commented Jul 16, 2014

Where does it violate the TrueType spec apart from having over 32k glyphs?

I do not understand why you are so fixed on this post table issue — for your build. Since your built of Unifont has useless glyph names (see “the third issue” above), [most probably] this table can be shorted arbitrarily, or removed completely without any ill effect.

However, for my build, this is a real issue — I use industry-standard glyph names, so they may be recognized/acted-upon. So: many many thanks for fixing this! ;-)

@ilyaza
ilyaza commented Jul 17, 2014

I did not have a goal of making something that could serve as a Windows console font for non-Asian scripts

The question is not about scripts; what is important is whether the glyphs are recognizable when squeezed into a monospaced BBox. For non-Han/Hangul, I strip a/b-gaps, and squeeze the rest horizontally; for Han+Hangul, this does not make a lot of sense — so in my build, I just do not include these characters. If a better strategy is discovered, they have a chance to be included in a later build.

Of course if I did that, then Unifont would not be a pan-Unicode font, so I would have to create a custom version for Windows' console mode.

??? You cannot have a “pan-Unicode” font in a TrueType format; period. So why bring this into the discussion? (And a major part of Unicode does not make sense with simple rendering anyway — while Unifont makes no provisions for complex rendering — and even for tolerable simple rendering!)

@paulhardy

Ilya,

On Wed, Jul 16, 2014 at 2:49 PM, ilyaza notifications@github.com wrote:

Two main issues are:

Aha! it looks like you read during those 2 minutes before I added the
third issue!

  • .notdef' of wrong width (conjecturally; I cannot test your build,
    since I expect it would play havoc on my computer — so it is possible.notdef`
    would not work at all);

    I am not a Fontforge expert. If you can provide Fontforge commands to
    define .notdef as some existing glyph, please do.

Somehow I do not follow… Paul, you DO realize that all the issues we are
discussing ARE fixed in my build — which is publicly available?


Reply to this email directly or view it on GitHub
#1031 (comment)
.

I have not had time to go through your software; I am extremely busy right
now in my personal life. If you can provide the Fontforge commands that
provide a definition for a ".notdef" glyph, however, I can try to add its
support for the next release.

On glyphs that Unicode has not yet defined, many Fontforge users and some
developers have asked me to include something to indicate them over time,
which is why I included the hexadecimal glyphs. A large number of those
requests came from people working on Windows.

I also created the Unifont SBIT version at the request of a Fontforge
developer in Germany. This is the "Sample" version, and it is pretty much
there just for Fontforge. The "Sample" fonts have hexadecimal glyphs for
unassigned code points, plus combining circles for all code points that are
combining characters. Those "sample" fonts are intended only for rendering
of isolated glyphs for illustration. If Fontforge can use the Unifont
Plane 0 SBIT version as a font for its sample glyphs (as Dave Crossland is
requesting in this thread), then the main TrueType version won't be driven
as much by requests from the Fontforge community. This is in flux and I
expect it to change in the future.

Paul

@ilyaza
ilyaza commented Jul 18, 2014

If you can provide the Fontforge commands that provide a definition for a .notdef glyph, however, I can try to add its support for the next release.

What I’m using is just

.notdef:FF808E9181A2A485A1254581897101FF
.null:
#   It is not clear how to make Encoding: -1 -1 2 to produce 2 -1 2 (either 65538 -1 2, or 2 2 2 IS possible to produce)
.nx.nonmarkingreturn:00000000000000000000000000000000

at the beginning of .hex file, and then filter the .sfd file to remove unicode indices (and .nx.):

@@ -58,7 +58,7 @@ TeXData: 1 0 0 346030 173015 115343 0 10
 BeginChars: 65536 3

 StartChar: .notdef
-Encoding: 4080 -1 0
+Encoding: -1 -1 0
 Width: 512
 Flags: W
 LayerCount: 2
@@ -172,14 +172,14 @@ EndSplineSet
 EndChar

 StartChar: .null
-Encoding: 4081 -1 1
+Encoding: -1 -1 1
 Width: 0
 Flags: W
 LayerCount: 2
 EndChar

 StartChar: nonmarkingreturn
-Encoding: 4082 -1 2
+Encoding: -1 -1 2
 Width: 512
 Flags: W
 LayerCount: 2
@ilyaza
ilyaza commented Jul 18, 2014

Hmm, patching is needed only because I need to filter the .sfd file through FontForge (to expand strokes). Since your workflow does not need this step, it is easier to just produce the needed -1s from the .hex-to-.sfd script.

@paulhardy

Ilya,

On Thu, Jul 17, 2014 at 5:13 PM, ilyaza notifications@github.com wrote:

If you can provide the Fontforge commands that provide a definition for a
.notdef glyph, however, I can try to add its support for the next release.

What I’m using is just...

Fontforge already includes definitions of .notdef, .null, and
nonmarkingreturn in the TrueType font, but as you noticed the spacing for
.notdef and nonmarkingreturn do not match the rest of the font. I'll see
about changing this in the next release.

Paul

@ilyaza
ilyaza commented Jul 21, 2014

Paul, I do not see what you can do in this case. We are discussing non-monospaced font here (with widths 0, 512, and 1024 — and line spacing 1024). Which width to use?

At some moment I did check what is the generated widths for a monospaced font. Since I did not file a bug report, it was probably OK. (Although I do not remember precisely now…)

@ytrezq
ytrezq commented Aug 10, 2015

I did the same with a monospaced version of ɢɴᴜ Unifont ᴄꜱᴜʀ and it changed nothing.
It seems though the font is only 16 ᴡindows® render it only at 12.
So, @davelab6 regarding your commit, thefontforge.FontView.FontSizeshould automatically set to an available font size when using bitmap fonts.

bdf file
The file above can be successfully converted to an outine fonts. However fontorge is unable to produce a bitmap .fon recognized by ᴡindows® (the font is generated without any warnings however ᴡindows® can’t open it).

An alternative would be to genrate a metric file for sbit32, the official ᴍicrosoft tool for creating bitmap TrueType bitmap fonts. The documentation about the file format is available with the tool.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment