Samuel, On Wed, Jun 18, 2014 at 7:22 PM, Samuel Bronson <naes...@gmail.com> wrote:
> Dear Paul Hardy, > > I want to start by saying that it was never my intention to insult you. > Okay. I would not have mentioned those things in a reopened bug report if I had gotten a reply to the private emails I sent to you. > Paul Hardy <unifoun...@gmail.com> writes: > > ... > > > > I am changing the severity of this to “wishlist” ... > > Huh; isn't it a bit redundant to change the severity as you close it? > Yes, but not if someone wound up reopening the bug, so I changed the severity before closing. > > Hmm, Section 5.3 appears to be targeted at implementations, including > renderers, not particularly at fonts. > > Which isn't to say that I think it's a bad idea to provide a TTF that > contains similar renderings of unassigned/private-use codepoint; I can > certainly see how the hex digits are preferable to Windows' default > rendering, for example. Note, however, that the version that Paul Wise > and I patched did not yet have these hex digits. > The Unicode Standard does allow such glyphs to be part of a font, for one reason so that consistent font spacing will apply even for undefined characters--and Unifont is a charcell font. I verified that my interpretation of Section 5.3 was correct in 2008 by asking the Unicode Consortium directly, and did so again in 2013. The same interpretation still applies. Of course rendering engines can do the same thing, and Section 5.3 of the standard contains suggestions that are optional for fonts and rendering engines alike. > ... > Well, I didn't really have any particular problem with the *packaging*, > besides the fact that it didn't rebuild the fonts from source, which > pabs and I took care of. > I wasn't satisfied with my own packaging, but wanted to get the font licensing issues out of the way first. The Fontforge operation of building the font was too much for some older build machines. It is a memory and CPU hog. For that reason and because the font files are architecture independent, I created a "precompiled" directory for pre-built font files and didn't build the font by default. > > My main problems with the package were (a) that the placeholder glyphs > made it impossible to use any more sophisticated fallback mechanism that > an application might support and (b) that my computer was too pathetic > to actually finish the conversion process in any sort of reasonable > timeframe. > The newest releases have this default: they provide hexadecimal glyphs for unassigned code points in scripts in the Basic Multilingual Plane, and do not provide glyphs for unassigned code points in the Private Use Area. That way someone who uses Unifont can also use their favorite PUA font in addition. This is also now a lot easier to customize. > > Fontforge can't just draw it's own hatched/hex/etc. boxes for missing > glyphs based on user preferences, which might well vary between the PUA > and the not-yet-in Uni(code|font)-codepoints? > Theoretically it could, but Fontforge has no built-in fonts. It specifically looks for Unifont as its fallback font. If Unifont isn't installed or doesn't have a glyph for a given code point, Fontforge relies upon the windowing system to render a glyph for the code point. Fontforge presents glyphs against a gray background, which is low contrast and can make a miniscule anti-aliased vector font (such as the gray glyphs that Gnome renders for unassigned glyphs) hard to read. I think that is why most people polled preferred the hexadecimal glyphs that Unifont now contains; they are white on black and so are higher contrast than Gnome's anti-aliased gray glyphs. I don't know for a fact why those taking the poll preferred the Unifont hexadecimal glyphs, but that is a likely explanation. > > But fontforge aside, it is indeed hard to please everyone; even if you > provide variants to suit all of the *picky* people, then you'll have > people complaining that it takes too much diskspace to store all the > variants, or that it's too hard to figure out which variant to use ... > > > I am finishing the proposed Unicode 7.0 Basic Multilingual > > Plane glyphs now but won’t release them until the formal release of > > The Unicode Standard version 7.0. > The Unicode Consortium formally released the Unicode 7.0 glyphs on 16 June 2013. I had been waiting for that and put a new version of Unifont online last night. I expect to have the new Debian package ready next weekend. > > ... > Well, either of the following would make me a lot happier: > > 1. Ideally, it would be possible to mark such glyphs as "fallback" > renderings, to be used essentially as "better tofu", since they have > the a reasonable width *and* show the hex digits. > I don't know how to do that, if it is even possible. > > 2. Since I'm pretty sure that's impossible, I'd like it if the user > could choose whether or not to use the placeholders. > The recent Unifont releases have separate "make" variables defined for different components of the font, to make it easy for someone to customize a build. For Unicode Plane 0, "PUA" is the variable for Private Use Area unassigned code points and "UNASSIGNED" for the unassigned code points outside the PUA. These can be set to a null string and those glyphs won't be compiled into the font. See the comments in the current debian/rules file and see the Unifont Texinfo documentation. That, along with going with what the majority of Fontforge GNU/Linux users who took the poll wanted, is what I have chosen. Not everyone will be happy with the default, but at least everyone can more easily build their own customized version if they do not want the default configuration. Having more variants of the font in the package would get unwieldy. Right now the gzipped tarball is on the order of 20 Mbytes, most of which is from the four pre-built TrueType fonts: Plane 0 with and without ConScript Unicode Registry (CSUR) PUA glyphs, and upper planes with and without CSUR PUA glyphs. So, um, sorry about all the muddy footprints we left on your lawn ... > I certainly don't mind someone making an improvement, but there are less insulting words in the English language. I found the "tofu" volley (which you didn't participate in) quite insulting and I didn't want to say anything at first. I thought it set the tone for what came after, but I want to drop the whole thing. Paul Hardy
