Bug#271427: another Debian font bug
Hi Daf, Today at 18:34, Dafydd Harries wrote: Is this problem only with Nimbus Mono? Perhaps you could provide a screenshot with a font that isn't broken for comparison purposes. Yes, this is a problem only with Nimbus Mono, and only with Oblique, Bold and Oblique Bold. I've checked Debian gsfonts-8.14+v8.11-0.1, and the problem exists there as well. It's correct in Valek's fonts, as you can see here: http://kvota.net/fonts/urwcyr/nimbus-mono-side-by-side.png Top fontforge view shows the font from your package, bottom is the one from gnome.ru 1.0.7-pre39 tarball (I use this one only because I'm lazy to download newer one, not because there's something wrong in later releases). So, this is entirely independent of the current bug, as Steve already pointed out. I think this is as bad as these missing/incorrect glyphs (Russians would probably argue that it's even worse ;), but it is nevertheless independent. Also, Nimbus Sans Regular and Regular Condensed look exactly the same for me (this could be due to some font fields not being set fully, but I'm not sure). Similarly, URW Bookman L Light gives me Demi Bold variant. For URW Gothic L, Book looks like Demi, and Demi Oblique looks like Book Oblique. Also, URW Palladio L Roman actually displays bold, just what Century Schoolbook L Roman does as well. All this is tested using gedit. It might conceivably be a problem with fonts being cached in some way. This persisted after reboot and fc-cache -f. fc-match[1] gives correct file pointers: $ fc-match urw palladio l URWPalladioL-Roma.pfb: URW Palladio L Roman $ fc-match urw palladio l:bold URWPalladioL-Bold.pfb: URW Palladio L Bold (These are links in /var/lib/defoma/... correctly pointing to /usr/share/fonts/type1/gsfonts.) [1] http://cvs.freedesktop.org/fontconfig/fontconfig/fc-match/ gcc -o fc-match `pkg-config --cflags --libs fontconfig` fc-match.c Could you see if you have these problems with the latest package in Debian? It would be useful to know whetehr these are regressions I've introduced or not. No, it seems this is not your fault. It happens just the same with previous Debian package. FWIW, this seems to be a problem with all type1 and some truetype fonts generated with FontForge (of those that I have, those are Computer Modern Unicode, your set of gsfonts, Caslon*.ttf by George Williams). Anyway, not related to this bug either. Cheers, Danilo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#271427: another Debian font bug
Today at 1:46, Dafydd Harries wrote: Ok, I now have a list of glyphs to copy based on your list and the ones which I've identified as broken. I've uploaded a new .deb, plus the latest versions of my scripts and their various outputs to the same location as before: http://muse.19inch.net/~daf/dump/271427/ I'll test these in Ubuntu now. Lets see how it goes. The copy-cyrillic.sh script contains the list of glyphs copied. Just a minor point, not very important anyway, since it's in a comment: # : U+040b : afii10060 : capital Tshe ^ this should be :) Yeah, it seems this was due to a bug in my script where it wouldn't copy the glyphs if they were not already in the target font. I've now fixed this, with some help from the Fontforge author. The only drawback is that these glyphs are added at the end of the font rather than inserted in order, but I don't think it's enough to worry about. This is no problem, because no modern client uses encoding vector in the font to access these glyphs anyway (since it's limited to 256 entries, and is probably AdobeStandardEncoding for GS fonts). I'll complain if I see any problem with fonts, but if I'm quiet, assume everything is fine. Cheers, Danilo
Bug#271427: another Debian font bug
Hi Steve, Today at 1:38, Steve Langasek wrote: I don't imagine that a private use glyph is anything we should be overly worried about release-wise... Provided how simple it is to actually integrate them as well, I see no reason not to. Adobe PUA is guaranteed to be static, and it's not really private either. I see no benefit in dropping them, and if you include them, there'll be less chances of multiple conflicting packages around, and people could actually start to build their software expecting to have these alternate glyphs. Of course, them missing should not block the release or be considered critical. Cheers, Danilo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#271427: another Debian font bug
Today at 17:04, Dafydd Harries wrote: Ah, this list is just what I need. However, there are some glyphs which are not in your list (see my previous mail to the bug report for details), but which also seem to be broken. Perhaps some non-Serbian Cyrillic glyphs are also broken. Yes, I've noticed that you mention it, but I really can't help there, since I'm not familiar with those glyphs, and how they're used or how should they look. My guess would be as good as yours. All Cyrillic outside 0x4000x45f range is used by non-Slavic Cyrillic languages, so I really don't know anything about it. The reason for this is that the Chancery font in the version of Valek's fonts which I grabbed doesn't seem to contain any of the Serbian glyphs. Also, the Nimbus Sans Condensed has a few broken/missing glyphs. I've just checked 1.0.7pre39 tarball, and it has all of these. I remember asking Valek to provide a SFD tarball a few releases before that, but that didn't come with Chancery fixed-up (it was fixed a release or two after the rest of the stuff), so perhaps you're using that one instead? Fontforge seems to be modifying the font metrics when I copy the glyphs, so I suspect it's happening automatically. Ah, ok, I just thought I'd mention it, since I'm not sure about it :) Unfortunately, the Debin bug tracking system doesn't have this feature yet. I'll keep you informed on developments. :) Thanks Daf, I really appreciate that! (It's been a mess trying to get this fixed up for Serbian, and I've been trying to do that for quite some time already.) Cheers, Danilo
