Bug#705233: node-cssom: patch
Package: node-cssom Followup-For: Bug #705233 Control: tags -1 +patch It looks like upstream introduced a Jakefile.js upstream which generates lib/index.js. Here is a patch that runs jake lib during build to generate the file. diff -Nru node-cssom-0.2.5/debian/clean node-cssom-0.2.5/debian/clean --- node-cssom-0.2.5/debian/clean 1969-12-31 19:00:00.0 -0500 +++ node-cssom-0.2.5/debian/clean 2013-04-11 11:58:53.0 -0400 @@ -0,0 +1 @@ +lib/index.js diff -Nru node-cssom-0.2.5/debian/control node-cssom-0.2.5/debian/control --- node-cssom-0.2.5/debian/control 2013-04-09 18:03:22.0 -0400 +++ node-cssom-0.2.5/debian/control 2013-04-11 11:54:50.0 -0400 @@ -3,7 +3,7 @@ Priority: extra Maintainer: Debian Javascript Maintainers pkg-javascript-de...@lists.alioth.debian.org Uploaders: Laszlo Boszormenyi (GCS) g...@debian.hu, David Paleino da...@debian.org -Build-Depends: debhelper (= 9) +Build-Depends: debhelper (= 9), node-jake Standards-Version: 3.9.4 Homepage: https://github.com/NV/CSSOM Vcs-Git: git://git.debian.org/collab-maint/node-cssom.git diff -Nru node-cssom-0.2.5/debian/rules node-cssom-0.2.5/debian/rules --- node-cssom-0.2.5/debian/rules 2012-03-22 16:19:17.0 -0400 +++ node-cssom-0.2.5/debian/rules 2013-04-11 11:58:57.0 -0400 @@ -4,5 +4,8 @@ # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 +override_dh_auto_build: + jake lib + %: dh $@ diff -Nru node-cssom-0.2.5/debian/clean node-cssom-0.2.5/debian/clean --- node-cssom-0.2.5/debian/clean 1969-12-31 19:00:00.0 -0500 +++ node-cssom-0.2.5/debian/clean 2013-04-11 11:58:53.0 -0400 @@ -0,0 +1 @@ +lib/index.js diff -Nru node-cssom-0.2.5/debian/control node-cssom-0.2.5/debian/control --- node-cssom-0.2.5/debian/control 2013-04-09 18:03:22.0 -0400 +++ node-cssom-0.2.5/debian/control 2013-04-11 11:54:50.0 -0400 @@ -3,7 +3,7 @@ Priority: extra Maintainer: Debian Javascript Maintainers pkg-javascript-de...@lists.alioth.debian.org Uploaders: Laszlo Boszormenyi (GCS) g...@debian.hu, David Paleino da...@debian.org -Build-Depends: debhelper (= 9) +Build-Depends: debhelper (= 9), node-jake Standards-Version: 3.9.4 Homepage: https://github.com/NV/CSSOM Vcs-Git: git://git.debian.org/collab-maint/node-cssom.git diff -Nru node-cssom-0.2.5/debian/rules node-cssom-0.2.5/debian/rules --- node-cssom-0.2.5/debian/rules 2012-03-22 16:19:17.0 -0400 +++ node-cssom-0.2.5/debian/rules 2013-04-11 11:58:57.0 -0400 @@ -4,5 +4,8 @@ # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 +override_dh_auto_build: + jake lib + %: dh $@
Bug#555168: Unclear license situation for (e)glibc locales provided by you
Indeed, the imaginet.co.uk address is not mine at all. I hereby licence all of my Debian translations under the GNU LGPLv2 or later. Is this sufficient? To the best of my memory, I was the sole contributor to d-i and probably any other Debian-specific translations. Regards, Daf Ar 09/06/2012 am 18:12, ysgrifennodd Christian PERRIER: Quoting Helge Kreutzmann (deb...@helgefjell.de): Hello, you are listed as contact person/author of the following locale: cy_GB Dafydd is a Debian Developer: his Debian address CC'ed as it might give better chances for him to get the mail. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633545: glitch: diff for NMU version 0.6-2.1
Ar 27/07/2011 am 21:10, ysgrifennodd Jakub Wilk: tags 633545 + patch tags 633545 + pending thanks Dear maintainer, I've prepared an NMU for glitch (versioned as 0.6-2.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Hi Jakub, You're welcome to NMU my package; I would appreciate it if you would also update the collab-maint repository for the package. http://anonscm.debian.org/gitweb/?p=collab-maint/glitch.git;a=summary Daf -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#494940: libloudmouth1-0: clients constantly get kicked
Ar 13/08/2008 am 11:55, ysgrifennodd Paul van Tilburg: Package: libloudmouth1-0 Version: 1.4.1-1 Severity: grave Justification: renders package unusable Hi! Clients that use LoudMouth constantly get kicked when used (at least) in combination with ejabberd. While my client (Gossip) on a NATed machine seems to have no problems, all clients (Gossip, Empathy) running on a machine directly connected constantly get kicked after 30s to 5 minutes of inactivity. Downgrading libloudmouth1-0 to version 1.4.0-1 seems to solve the problem. Since LM does not offer much debug feedback on disconnecting, I cannot provide more info than the following output: SEND: --- --- Freeing up IOChannel and file descriptor [...] and then the client starts reconnecting. Regards, Paul This is very weird. The only change in 1.4.1 was to revert a change to use TCP keepalives instead of whitespace keepalives, as TCP keepalives caused problems with some NATs. Perhaps you could check whether this happens with 1.4.0 and maybe the last 1.3 version (I forget the exact number). -- Dafydd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445726: libjinglebase0.3-0: Parts of libjinglebase is GPLv2 licensed and it links to OpenSSL
Ar 07/10/2007 am 23:03, ysgrifennodd Thadeu Lima de Souza Cascardo: Package: libjinglebase0.3-0 Version: 0.3.11-1 Severity: serious Justification: Policy 2.3 In the copyright file of libjinglebase, the Affine code is said to be licensed under the GPL version 2 or later. OpenSSL license is incompatible with GPL, as known by many. The usual options are: * ask permission to the said code to relicense (perhaps an exception allowing to link to OpenSSL) * remove or rewrite the said Affine code * remove OpenSSL support when building * try to use GNUTLS compatibility with OpenSSL * replace OpenSSL with GNUTLS or NSS, rewriting SSL/TLS support I can't find the code this copyright statement refers to. Presumably the code was removed upstream since that copyright notice was written. This suggests that the appropriate fix is to just amend the copyright notice. -- Dafydd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445726: libjinglebase0.3-0: Parts of libjinglebase is GPLv2 licensed and it links to OpenSSL
Ar 07/10/2007 am 23:03, ysgrifennodd Thadeu Lima de Souza Cascardo: In the copyright file of libjinglebase, the Affine code is said to be licensed under the GPL version 2 or later. OpenSSL license is incompatible with GPL, as known by many. The usual options are: * ask permission to the said code to relicense (perhaps an exception allowing to link to OpenSSL) * remove or rewrite the said Affine code * remove OpenSSL support when building * try to use GNUTLS compatibility with OpenSSL * replace OpenSSL with GNUTLS or NSS, rewriting SSL/TLS support I suspect we might just be able to remove this code. Will investigate. -- Dafydd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420745: gossip: Gossip forgets all its accounts
Package: gossip Version: 0.24-2 Severity: grave Justification: causes data loss When I started Gossip after upgrading to version 0.24, I started up with the account creation dialog. All my accounts had been removed from ~/.gnome2/Gossip/accounts.xml. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397929: libtelepathy: FTBFS: error while loading shared libraries: libexpat.so.1
Ar 10/11/2006 am 15:20, ysgrifennodd Julien Danjou: dbus-binding-tool --prefix=tp-connmgr --mode=glib-client ../xml/modified/tp-connmgr.xml tp-connmgr-gen.h dbus-binding-tool: error while loading shared libraries: libexpat.so.1: cannot open shared object file: No such file or directory Hmm: - libtelepathy uses dbus-binding-tool - dbus-binding tool is contained in libdbus-glib-1-dev - libtelepathy build-depends libdbus-glib-1-dev - lidbus-glib-1-dev depends on libexpat1 - libexpat1 contains libexpat.so.1 I don't understand what's going wrong. -- Dafydd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396862: libgtk-mozembed-ruby: FTBFS: checking for xulrunner-gtkmozembed... Ruby/GTK couldn't be initialized ('Cannot open display: ')
Ar 03/11/2006 am 13:08, ysgrifennodd Andreas Jochens: Package: libgtk-mozembed-ruby Version: 0.3.1-6 Severity: serious When building 'libgtk-mozembed-ruby' in a clean unstable chroot, I get the following error: This source package is deprecated. It has been merged upstream into the ruby-gnome2 source package. The libgtk-mozembed-ruby binary package Replaces/Provides libgtk-mozembed-ruby1.8. If libgtk-mozembed-ruby1.8 is still in the archive, it should be removed. -- Dafydd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393821: patch
Uploading an NMU with the following patch: diff -urN haskell-utils-1.6.0.1/Makefile haskell-utils-1.6.0.1.new/Makefile --- haskell-utils-1.6.0.1/Makefile 2004-10-31 01:27:12.0 + +++ haskell-utils-1.6.0.1.new/Makefile 2006-10-28 13:26:43.0 +0100 @@ -21,6 +21,10 @@ all: $(PROGRAMS) $(MANPAGES) +ifeq $(COMPILER_NAME) ghc6 +COMPILER_FLAGS := $(COMPILER_FLAGS) -package regex-compat +endif + $(PROGRAMS): %: %.lhs ifeq $(COMPILER_NAME) hugs (echo #!/usr/bin/runhugs +l; cat $) $@ -- Dafydd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394239: non-determinism
It seems that the TestGraphStuff test case is non-deterministic. However, it only seems to fail when the tree has .pyc files in it. One failure has the tests in the following order: [testresources.tests.test_optimising_test_suite.MockTest testMethod=test_two, testresources.tests.test_optimising_test_suite.MockTest testMethod=test_three, testresources.tests.test_optimising_test_suite.MockTest testMethod=test_one, testresources.tests.test_optimising_test_suite.MockTest testMethod=test_four] By the way, the source package seems to have a .bzr directory; I expect this was accidental. :) -- Dafydd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379281: python-pyxmpp: missing dependency on python-dnspython
Package: python-pyxmpp Version: 1.0.0-1.1 Severity: grave Justification: renders package unusable Attempting to import the Stream class yields the following error: Traceback (most recent call last): File server.py, line 4, in ? from pyxmpp.stream import Stream File /var/lib/python-support/python2.4/pyxmpp/stream.py, line 29, in ? from pyxmpp.streambase import StreamBase File /var/lib/python-support/python2.4/pyxmpp/streambase.py, line 47, in ? from pyxmpp import resolver File /var/lib/python-support/python2.4/pyxmpp/resolver.py, line 30, in ? import dns.resolver ImportError: No module named dns.resolver Installing the python-dnspython package solves the problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309146: Debian Bugs information: logs for Bug#309146
Ar 17/05/2005 am 09:18, ysgrifennodd Debian Bug Tracking System: Package: install Severity: critical Tags: experimental Justification: breaks the whole system when upgrade from stable to unstable, and network card is pcmcia card, after near upgrade is complete, pcmcia-cs package is not installed. it's mean installation loose connection to internet and there is no way to finish rest of instalation - like 'module-init-tools', 'debconf', 'debconf-i18n'. Hi, On this page: http://release.debian.org/upgrade-report.html there is a list of information that is useful when helping us work out what went wrong with an upgrade. Could you tell us more about what happened, using the questions on that page? Regards, -- Dafydd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295556: FWD: [SECURITY] [DSA 684-1] New typespeed packages fix arbitrary group games code execution
Ar 17/02/2005 am 06:29, ysgrifennodd Martin Schulze: Dafydd Harries wrote: Filing this bug to track the security hole in the DSA below. Apparently a fix for unstable has not yet been uploaded. Since I don't have a copy of the original security patch, I tried to extract the changes by interdiffing the fixed stable version with the latest unstable version. The changes to network.c and typespeed.c apply cleanly, but the changes to file.c don't. I'm working on resolving those conflicts. Oh. I have to apologise since apparently I sent my mail to the wrong address. apt-cache show displayed two versions of typespeed and I didn't check the version number when extracting the maintainer address. I usually contact sid maintainers before releasing an advisory. Ah, that explains why the first I heard of it was the mail to debian-security-announce. ;) Not to worry. :) -- Dafydd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#271427: copying glyphs between fonts
Ar 07/02/2005 am 10:45, ysgrifennodd George Williams: On Sat, 2005-01-29, someone wrote Also note that there're two modes of copying in FontForge: with metrics, or just glyph outlines (without metrics). For all of these glyphs, you want to copy metrics over as well. I don't know how this is exactly done from scripts, but there's a Copy metadata in the Edit menu somewhere, which modifies the basic copying behaviour in UI. Perhaps Copy() works this way from scripts by default. Copy metadata isn't apropos here. That copies glyph-names unicode code point as well as outlines. Whether the advance width is copied (I assume that's what is meant by with metrics) depends on whether you do a Paste() which clears out the old glyph (if any) and replaces it with the new. This copies the advance width too. Or PasteInto() which adds the outlines in the clipboard to the destination glyph (and leaves the previous stuff there). This does not change the advance width. Right, Paste() is what I've been using, and I gather from what you say that it's what's appropriate for this situation. On Thu, 2005-02-03 at 14:38, Dafydd Harries wrote: The results are mostly successful, but there are some problems with the sizes (metrics?) of some glyphs in some of the fonts, which aren't present in the fonts I copied them from. I don't understand what you are saying. When ff copies a glyph from one font to another it should not change it in any way. If you copy a glyph into a mono-space font it will not be adjusted to fit. If you copy a glyph into a font with a different em-size, cap-height, x-height, etc. it will not be adjusted to fit. Aha, perhaps these adjustments need to be made in some cases, if the em-size or some other parameter different between the two version of the fonts. It seems to me that this might not be something that can be automated, though. If they are different, it's odd that the problem has somehow happened in the first place. Similarly copying a glyph should not change any other glyphs (except for those which refer to the copied glyph) If you have a glyph that has been changed by the copying process, that is a bug in fontforge. But I don't know enough about how the glyphs in http://kvota.net/fonts/urwcyr/nimbus-mono-side-by-side.png were generated to tell what's going on. I think 271427 is saying that this bug has nothing to do with the copying you've done and is a separate issue? Shouldn't you just copy the glyphs from Valek's fonts? Yes, it seems all of the remaining problems in the fonts were not introduced by my changes. Thanks for looking at this bug. -- Dafydd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#271427: another Debian font bug
I've just realised that it's Florian, who did the last (NMU) upload of gsfonts, who is the submitter of this bug and not Stefan, who reported the bug originally as #250949. I'm CCing Stefan. Stefan, if you'd like to catch up on what's been happening, the bug log is available here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=271427 If you could test my packages (details below) and verify that they fix the problem, I would be very grateful. Ar 29/01/2005 am 18:35, ysgrifennodd Danilo egan: 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. 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/ The copy-cyrillic.sh script contains the list of glyphs copied. 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? 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. By the way, my work is based on the 1.0.7pre40 tarball from gnome.ru. The main remaining issue seems to be that Fontforge is causing spurious changes to the font metrics in some cases. I'm going to pursue this with the Fontforge author. Something else to note is that neither the GhostScript fonts nor Valek's fonts contain glyphs for U+04a2 () and U+04a3 () in Nimbus Sans L Bold Condensed (n019044l.pfb). One thing that needs some consideration is which version number to give this updated package. The three most recent versions were: - 8.14-3. - 8.14+urwcyr1.0.7pre35-1, which I understand used Valek's fonts as upstream source. - 8.14+v8.11-0.1, Florian's NMU which reverted the .orig.tar.gz back to that of 8.14, in order to fix the metrics problems introduced by the previous upload. I guess 8.14+urwcyr1.0.7pre40 will do for the upstream version. -- Dafydd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#271427: another Debian font bug
Ar 29/01/2005 am 13:49, ysgrifennodd Danilo egan: Heya Daf, Nice to see a known name working on thisit gives me a warm and fuzzy feeling :) Well, I got a nice feeling when I saw that you've been working on this stuff before. :) Today at 9:14, Dafydd Harries wrote: I've been working on a font bug that's popped up in Debian. It's about Cyrillic glyphs in the Ghostscript fonts, and I noticed when reading old reports that you've worked on similar bugs before. I think I've made some progress tonight on fixing it. Your input would be appreciated. Sure, here you go. Feel free to repost any or all of this to the bug-alias. Great, CCing the bug. Here's the bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=271427 Strictly Serbian glyphs (used in none of the other Cyrillic languages, except maybe some of them in Macedonian, but the same explanation holds for them as well) are the following: U+402 and U+452 (, , DJE), which you mention to have fixed already U+408 and U+458 (, , JE), which are exactly the same as Latin J, so there should be no problems with these U+409 and U+459 (, , LJE) U+40a and U+45a (, , NJE) U+40b and U+45b (, , TSHE) U+40f and U+45f (, , DZHE) In addition to these, there're some variants in Adobe PUA (Private Use Area), where same characters have slightly different appearance in Serbian and Russian: U+f6c4: small cyrillic (U+433), different only in italic variants U+f6c5: small cyrillic (U+431), which differs even in regular faces U+f6c6: small cyrillic (U+434), different only in italic variants U+f6c7: small cyrillic (U+43f), different only in italic variants U+f6c8: small cyrillic (U+442), different only in italic variants (These also have AFII glyph names [eg. U+f6c5 is afii10063], but they seem to go only by generic Unicode-based names of uniF6C5 and similar in generated PFB files from Valek.) 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. All of these are correct in latest Valek's fonts, so you want to merge them. Also, in your copy-glyphs.sh script, you seem not to be fixing URW Chancery font (z003034l.*), which also needs correction on all of these (including above cursive variants). 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. Also note that there're two modes of copying in FontForge: with metrics, or just glyph outlines (without metrics). For all of these glyphs, you want to copy metrics over as well. I don't know how this is exactly done from scripts, but there's a Copy metadata in the Edit menu somewhere, which modifies the basic copying behaviour in UI. Perhaps Copy() works this way from scripts by default. Fontforge seems to be modifying the font metrics when I copy the glyphs, so I suspect it's happening automatically. I looked in the Fontforge scripting reference (http://fontforge.sourceforge.net/scripting.html) and couldn't find much information either way, though there's a CopyGlyphFeatures function which looks like it may be used to copy some metadata. I have not yet learned how to watch a certain Debian bug, so please keep me in CC, if you expect further responses from me :) Unfortunately, the Debin bug tracking system doesn't have this feature yet. I'll keep you informed on developments. :) -- Dafydd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#271427: some progress
I think I've made some progress on this. I investigated the possibility of using Fontforge to script the copying of glyphs from one font to another, and it turns out that this is quite easy. I have written two scripts: - A Fontforge script which copies a single glyph from one font to another. - A shell script which copies Serbian glyphs for each of the broken fonts. The list of broken font files is based upon the information in the original bug report about which fonts have problems. Since I can't read Cyrillic, the only glyphs that are copied are - small Tshe (aka U+0452, afii10099), because it was mentioned in the original report, and - large Tshe (aka U+0402, afii10051), because I'm guessing that that's wrong too, due to the fact that it's different in Valek's version. It should be trivial to make the shell script copy other glyphs across, or to copy between additional fonts. If somebody can provide me with a comprehensive list of the glyphs that are broken, this would be very useful. The script also uses the afmutil.py script you mentioned to generate a diff between the AFM file before the copy and the same file afterwards, ignoring changes in comments and such. I ran the scripts on the fonts in the gsfonts package to copy glyphs from the fonts in ftp://ftp.gnome.ru/fonts/urw/release/urw-fonts-1.0.7pre40.tar.bz2 I saw some side-effects to the metrics of the scircumflex and jcircumflex characters, but only very small ones (i.e. two numbers being changed by 1). I'm guessing these might be due to a rounding error in Fontforge or something like that. Other than that, the only changes are to comments and to the metrics of the glyphs in question. I don't know if hinting has been affected. I have uploaded the two scripts I wrote, afmutil.py (for convenience), a a HTML page for testing the fonts, a screenshot of that page on my system, and a Debian package with the modified fonts, to the following location: http://muse.19inch.net/~daf/dump/271427/ In the screenshot, Schoolbook and Palladio look fine. Some fonts don't appear to have bold variants. Nimbus Roman seems to have a buggy italic variant, and Bookman has buggy glyphs for all variants, though small Tsche seems fine for the Roman variant. The possibility that some of the old versions of the fonts might still be hanging around in memory or something like that, might account for some of these problems, though. -- Dafydd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#271427: Debian bug #271427
I've been taking a look at this bug and trying to understand the situation. As far as I can tell, upstream releases are at ftp://mirror.cs.wisc.edu/pub/mirrors/ghost/fonts/ and there is a derivative set of fonts by Valek Filippov at ftp://ftp.gnome.ru/fonts/urw/release/ which contains extra Cyrillic glyphs, but not all of the glyphs in the original font. Upstream is aware of the problem with the font and is trying to coordinate a new release, but it seems there is some sort of communication problem with Valek. I don't understand how changes are merged back and forth between these branches. A glance at Century Schoolbook L Roman from both sources indicates that the former has an incorrect version of U+045B and that the latter has a a correct version. It seems to me it would be possible to use Fontforge (or a comparable tool, if one exists) to copy-and-paste the correct glyphs by hand from Valek's fonts into each of the problematic ghostscript.com fonts without any undesirable side-effects. Since the .pfb files are binary, it will not be possible to generate a patch, but the modified .pfb and .afm files will need to be copied into the source of the package and a new version number decided upon. -- Dafydd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
