Dear Paul Hardy, I want to start by saying that it was never my intention to insult you.
Also, in an effort to avoid a never-ending fight, I'm refraining from reopening the bug. I don't even particularly need the TTF on Debian, and if I want a newer version my way, I guess I can just do the same thing again and have the OpenSUSE build farm build it for me; it's not as though I'd need to upload the result to Debian. However, I'm afraid I don't have the self-restraint to refrain from commenting on some of your specific statements. Paul Hardy <unifoun...@gmail.com> writes: > severity 584672 wishlist > > close 584672 > > thanks > > Samuel, > > I am changing the severity of this to “wishlist” because this is not a > real bug. Unifont conforms to The Unicode Standard. It did in 2008 and > it does now. The current Unifont doesn’t even contain the glyphs > mentioned in this bug report so I am closing it. Huh; isn't it a bit redundant to change the severity as you close it? > I took the time to email you about the earlier glyphs following > explicit suggestions of The Unicode Standard for Unicode fonts. For > example, see Section 5.3 of the Standard. I verified my correct > interpretation of Unicode in 2008 before releasing those glyphs by > asking The Unicode Consortium. I verified again in 2013 that those > glyphs still conformed to the latest Unicode Standard, and they do. > However, those glyphs are no longer even a part of Unifont so there is > no point in re-opening this bug. 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. > This is after your derisive and untrue comment about my work being > “bogus” as well. That followed the abusive “tofu” insult made > previously in this thread, so maybe you thought from that precedent > that such provocation was acceptable. I don’t. My use any terms such as "bogus", "dummy", and "tofu" were not intended as a personal attack. In a technical context, "bogus" and "dummy" are often used to refer to any sort of placeholder or stand-in. In this context, the term "tofu" just refers to those little boxes that one tends to get when the text renderer can't find a font that contains a glyph for a given codepoint, or to anything of a similar nature that might actually be present in a font. Not a good thing, to be sure, but neither is it an insult to the fontmaker. Now, it's true that the term "bogus" has negative connotations; I used it because I was kind of grumpy about the fact that Unifont's placeholder glyphs were preventing any further attempts at fallback for codepoints that hadn't yet been defined when that release of Unifont was made. > I wanted to give you the benefit of the doubt, and so five months ago > offered in good faith to let you participate in the packaging of a new > version along with Paul Wise. In particular, I wanted Paul to have the > opportunity to see Unifont packaged the way he wanted. Neither of you > took me up on the offer. I've already put the effort in to convert the > package to the new dh mechanism and then converted it to the quilt > format. There’s nothing left to do Debian packaging-wise. 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. 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. > Then in December, while making sure I had properly closed a bug that > someone filed on Ubuntu in September, I saw that you created a > “Unifont Team” with yourself as owner/moderator (with your lack of > understanding of The Unicode Standard) and me as a member. That > created a false public impression that somehow you and I were on some > sort of team together, which has never been true. It also carried the > implication that I endorsed what you did, which was also not the case. > After emailing you about that with no response from you, I removed > myself from that “Team” page to bring an end to such > misrepresentation. Ah, sorry about that; I made that "team" *ages* ago (notice the Creation date, and the Last Modified dates on the branches?), My motivation for making the team was was something like this: I wanted a Launchpad project to associate a couple of bzr branches with, but I didn't want to prevent you from administering that project after I inevitably forgot about it and failed to notice any related emails, so I created the team and put you on it. (I think they since added some sort of "orphanage" team that one is supposed to donate such projects to?) I have now set you as the owner of this team, added a disclaimer stating that my [former] membership on the team should not be taken as implying that you approve[d] of any of my actions, and removed myself from the team. Sorry I'm so bad at reading my mail :-(. > There are tens of thousands of packages in Debian. Why not find one > that interests you whose maintainer’s work you have not insulted. A > package where you haven’t created the false impression that you and > the maintainer were on some sort of team together. One whose > associated standards you’ll put in the time to learn. There’s bound to > be a few hundred packages that would meet such selection criteria. > > Evidently others in the Debian font group were not that familiar with > The Unicode Standard either. Before Unicode 6.0 it was necessary to > purchase a physical copy of the latest standard, which I had been > doing over the years. That was an expense most people obviously would > not want to incur; those books weren’t cheap. However, The Unicode > Standard is now available as a free PDF download from > http://unicode.org so there’s no reason for those who have a sincere > interest in Unicode not to educate themselves. Why is it that you believe that the Debian font group (with whom I'm not really affiliated) is unfamiliar with the Unicode standard? > I also had conflicting requests from the Fontforge community. Unifont > is the font of last resort for Fontforge. Because Fontforge is used to > create new free fonts, the Fontforge/Unifont combination has a > multiplying factor. So I weigh the wishes of Fontforge users very > heavily. Some Fontforge users wanted to retain the shaded box glyphs > for unassigned code points exactly because they followed a Unicode > recommendation, mimicking the appearance of the Unicode code charts. > One person had a very strong opinion about this and gave me a number > of reasons for keeping the glyphs as they were in 2008. > > With Paul Wise not taking me up on my offer to participate in > packaging the new version the way he wanted, I asked the GNU/Linux > Fontforge community which they preferred for the appearance of > unassigned glyphs. Knowing there were conflicting wishes among users, > I took the trouble of creating a poll on my website, deciding to > implement whatever the majority who voted wanted. I offered five > choices: the default on whatever GNU/Linux windowing system they were > using (listed as the first choice to give it the most prominence), or > the new hexadecimal glyphs I had created, or the original shaded box > from 2008, or two other variants of shaded boxes with wider stripes. > > I also emailed Paul Wise, inviting him to participate in the poll so > his vote would be counted. > > I don’t know who specifically did or did not vote in the poll though; > it was anonymous. > > I needed to resolve this quickly because Fontforge was preparing its > most major release in a couple of years at the end of December. That > was just a few weeks from my putting the poll online. I needed to > freeze a version of Unifont that the Fontforge team could rely upon > quickly. > > You can see the results of the poll here: > http://unifoundry.com/poll_unassigned/index.php. I thought there would > be more voting but it trailed off to almost nothing after the first > day. Most GNU/Linux Fontforge users wanted the new hexadecimal glyphs > I had created, more than all other options combined. So I went with > that option and released the font a couple of weeks in advance of the > scheduled major Fontforge release. 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? 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 ... > The new glyphs still conform to The Unicode Standard, following a > different suggestion. This is also mentioned, for example, in Section > 5.3 of The Unicode Standard. In any case they are not the subject of > this particular bug report. Yeah, isn't quite the subject of the bug report as originally written; I guess I shouldn't have reopened it without explanation :-(. [Explanation of the release taking a while while thousands of glyphs were drawn omitted.] > Fortunately I will never have to draw a block of over 11,000 glyphs > again. 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. > > There are currently only 2,325 unassigned glyphs in the Unicode 6.3 > Basic Multilingual Plane. There should be fewer than 2,000 unassigned > glyphs in the BMP once Unicode 7.0 is released. Thus out of the 64k > code points in the Basic Multilingual Plane, having these hexadecimal > unassigned glyphs just adds a few percent to the size of the > uncompressed font, which is insignificant. Was I complaining about the size of the font? Well, that was certainly not my main point; what gets my goat is if I (or, well, anyone) get stuck using a font that has placeholders for since-assigned codepoints. Which *can* happen even if it's been updated upstream and in sid -- say, if I'm trying to use it on a Windows system too. > In the end, this is just one font. I have catered to the wishes of the > GRUB and especially Fontforge communities, but there will never be > perfect agreement among all. There are thousands of other fonts that > are true outline fonts with much nicer rendering than Unifont. No one > font could possibly satisfy everyone in every way. If this font > doesn’t suit you (and I expect it would not suit most people for > constant use), there is a vast array of alternatives. 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. 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. a. This would be easy to do with OpenType features, but the applications that support those are roughly the LEAST likely to benefit from the toggle, so it probably wouldn't be particularly useful ... b. So I guess this would involve shipping two TTF files. While thinking about how vexing it is that 2b would use roughly twice as much space as 2a, I naturally got to wishing you could re-use outlines *between* TTF files like you can within a single file; this lead me to think about: i. How it would have saved space to re-use the outlines of the duplicate placeholders in the old, lots-of-clones version But yes, perhaps I should use other fonts more. I'll probably continue to use this font on my non-*nix systems, since hardly anything there knows how to use real bitmap fonts, nevermind mix-and-match them. On Debian, however, I guess I really don't need the TTF anymore now that I know how FreeType can render bitmap fonts directly (but don't let it try to bold them; it does an insanely bad job of it compared to what xterm can do!) So, um, sorry about all the muddy footprints we left on your lawn ... -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
