Bug#972896: libgs9-common: please relax the dependency on fonts-urw-base35

[Fabian Greffrath]

Am 2020-10-26 11:01, schrieb Jonas Smedegaard:

Your signalling that you think I am an idiot does not help here.


I absolutely do not think you are an idiot! Quite the contrary, I assume 
you to be a very intelligent person, thus I wonder why you ask me to 
repeat my arguments over and over again.



Please keep such provocations to yourself!


Indeed, sorry for the provocation.


I will have ghostscript tell dh_linktree to relax its checks to only be
concerned about paths (not content), which should lead to somewhat
relaxed versioning of dependency for future migrations.


I believe this is the right thing to do. Thanks for that!

 - Fabian

Bug#972896: libgs9-common: please relax the dependency on fonts-urw-base35

[Fabian Greffrath]

Am 2020-10-26 09:56, schrieb Jonas Smedegaard:

You cannot mean to sugges that ghostscript should violate Debian Policy
by ignoring the integrity of symlinks, so it must be something else.
Please elaborate what you have in mind.


*Sigh!*

Please reconsider letting unrelated packages migrate to testing by not 
applying an upper bound to their version number in your package's 
dependencies. Please expect other package maintainers to behave well and 
not change file paths which would break your package but require not 
much more than a trivial rebuild. Thanks!


 - Fabian

Bug#972896: libgs9-common: please relax the dependency on fonts-urw-base35

[Fabian Greffrath]

Am 2020-10-25 22:48, schrieb Jonas Smedegaard:

It seems to me that the concrete delay is caused by ghostscript in
_testing_ having tight dependency on the font, and that it therefore
cannot be solved by an upload to unstable - only by ghostscript
migrating to testing (or ghostscript getting kicked out of testing).
That said, relaxing the dependency would avoid similar delays in the
future.


Indeed, it is the ghostscript package in testing that blocks the 
migration of the font package due to its strict dependencies which limit 
the font package's version number to an upper bound. Both packages are 
currently forced to migrate in lockstep.



The reason for the tight dependency is to ensure the integrity of the
symlinking between the font package and Ghostscript.  It is resolved by
dh_linktree which explains it like this in its man page:


I see. But by applying this measure you prevent the usual case, i.e. 
packages migrating independently, in order to avoid the very uncommon 
and unexpected case, i.e. file locations getting out of sync. Please 
reconsider.


 - Fabian

Bug#972896: libgs9-common: please relax the dependency on fonts-urw-base35

[Fabian Greffrath]

Package: libgs9-common
Version: 9.52.1~dfsg-1
Severity: important

Hi there,

the fonts-urw-base35 is currently stuck in unstable and not allowed to
migrate to testing because the ghostscript package currently suffers
from a completely unrelated RC bug. This is because the libgs9-common
package has an overly strict dependecy on fonts-urw-base35:

Depends: fonts-urw-base35 (<< 20170801.1.0~), fonts-urw-base35 (>= 20170801.1)

Thus, the font package is punished for a bug in ghostscript that's not
even related to the font at all. Please relax the dependency to just
the "fonts-urw-base35 (>= 20170801.1)" part so that newer versions of
the font than the one the ghostscript package was built with are
allowed to migrate to testing.

Thanks!

 - Fabian


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'experimental'), 
(500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libgs9-common depends on:
ii  fonts-urw-base35  20170801.1-3

Versions of packages libgs9-common recommends:
ii  fonts-droid-fallback  1:6.0.1r16-1.1

libgs9-common suggests no packages.

-- no debconf information

Bug#613912: closed by Jonas Smedegaard (Bug#613912: fixed in ghostscript 9.27~dfsg-3)

[Fabian Greffrath]

Am Mittwoch, den 24.07.2019, 16:12 + schrieb Debian Bug Tracking
System:
> #613912: ghostscript ships its own fonts in libgs9-common,
> additionally depends on gsfonts

Cool, thanks!

 - Fabian



signature.asc
Description: This is a digitally signed message part

Bug#663192: [Pkg-cups-devel] Bug#663192: cups-filters: Please add support for embedding of Opentype fonts

[Fabian Greffrath]

Am Mittwoch, den 15.03.2017, 17:33 + schrieb Brian Potkin:
> Where are we up to with this report; I am unfamiliar with font
> handling so cannot tell. Is the issue fixed or are there aspects
> still to be dealt with?

I just added some fontconfig handling, so I consider my job done.

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#767325: Please package a new HPLIP upstream release, really

[Fabian Greffrath]

Am Mittwoch, den 18.11.2015, 13:53 +0100 schrieb Fabian Greffrath:
> But what would help even more would be an estimate date when this
> package will be available. Or, even better, what is missing in Debian
> that delays the upload? What is keeping you from uploading?

Well, great! Three days later 3.15.11 has been uploaded to Ubuntu but
not to Debian. Is there a specific reason for neglecting Debian?

Regards,

Fabian


signature.asc
Description: This is a digitally signed message part

Bug#767325: Please package a new upstream release, really

[Fabian Greffrath]

Dear Printing Team,

HPLIP 3.15.x is required for the printer that I just bought yesterday.
I have seen that this version is already packaged for Ubuntu and it's
nice to see that all bug reports requesting its upload to Debian are
tagged as "pending" dating back to 22 Feb 2015.

But what would help even more would be an estimate date when this
package will be available. Or, even better, what is missing in Debian
that delays the upload? What is keeping you from uploading?

How can I help?

Thank you!

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#791766: /usr/lib/cups/backend-available/usb: USB backend eats 100% CPU

[Fabian Greffrath]

Am Montag, den 14.09.2015, 13:49 -0300 schrieb Till Kamppeter:
> The fix I have backported to said cups release.

Fine, but why have you set yourself as Author for the patch?

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#791766: /usr/lib/cups/backend-available/usb: USB backend eats 100% CPU

[Fabian Greffrath]

Control: forwarded -1 https://www.cups.org/str.php?L4707


signature.asc
Description: This is a digitally signed message part

Bug#791766: /usr/lib/cups/backend-available/usb: USB backend eats 100% CPU

[Fabian Greffrath]

Am Donnerstag, den 09.07.2015, 14:11 +0100 schrieb Brian Potkin:
> The word "sometimes" isn't one which brings joy to the heart when bug
> hunting. :)

In this context, I suspect that "sometimes" is related to Windows 7
running (or not) as a guest system in VirtualBox and trying to access
the USB ports of my host system which is running Debian and thus cups.

 - Fabian



signature.asc
Description: This is a digitally signed message part

Bug#791766: /usr/lib/cups/backend-available/usb: USB backend eats 100% CPU

[Fabian Greffrath]

Control: tags -1 + patch upstream

Hi again,

Am Donnerstag, den 09.07.2015, 16:53 +0200 schrieb Fabian Greffrath:
> Thus, I assume that the following patch might work, but i am not sure
> yet, because, you know, it only happens "sometimes". ;)

now I have proof that it works!

My printing was hanging again today, with the "usb" process eating up
100% CPU. It's process ID was 24901 and so I attached GDB to it. Look
what happened:

$ sudo gdb /usr/lib/cups/backend-available/usb --pid 24901
[...]
(gdb) bt
#0  0x7f7884939c17 in ioctl () at ../sysdeps/unix/syscall-template.S:81
#1  0x7f78850ad4d1 in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0
#2  0x7f78850a7950 in libusb_claim_interface () from 
/lib/x86_64-linux-gnu/libusb-1.0.so.0
#3  0x7f78854e0ee8 in open_device (printer=0x7f78856e51c0 , 
verbose=1)
at usb-libusb.c:1515
#4  find_device (cb=0x7f78854e0900 , data=0x7f7885e3c630) at 
usb-libusb.c:942
#5  0x7f78854e1a98 in print_device (uri=0x7f7885e3c630 
"usb://Kyocera/FS-1120D?serial=Q5Y1358476", 
hostname=, resource=, options=, print_fd=0, copies=1, 
argc=6, argv=0x7ffd7b31d838) at usb-libusb.c:220
#6  0x7f78854df603 in main (argc=6, argv=0x7ffd7b31d838) at usb.c:248

(gdb) frame 3
#3  0x7f78854e0ee8 in open_device (printer=0x7f78856e51c0 , 
verbose=1)
at usb-libusb.c:1515
1515usb-libusb.c: Datei oder Verzeichnis nicht gefunden.

So, it was hanging in line 1515 of usb-libusb.c, just as I suspected.

(gdb) p printer
$1 = (usb_printer_t *) 0x7f78856e51c0 
(gdb) p *printer
$2 = {device = 0x7f7885e3fde0, conf = 0, origconf = 0, iface = 0, altset = 0, 
write_endp = 0, 
  read_endp = 1, protocol = 2, usblp_attached = 0, reset_after_job = 0, quirks 
= 0, 
  handle = 0x7f7885e43f00}

This was just a test to see if the struct was still intact, all looked good.

(gdb) p libusb_detach_kernel_driver(printer->handle, 
printer->iface)libusb_claim_interface
$3 = 0
(gdb) c
Continuing.

And indeed, it broke the loop and printing continued! So, it makes
sense to check if the error code of libusb_claim_interface() is indeed
LIBUSB_ERROR_BUSY and add another call to libusb_detach_kernel_driver()
if it is. I have no idea, though, why it is possible that the device is
reported busy at this stage, as it is already checked earlier in the
code and clearly *shouldn't* be at this point, but apparently it is
possible and calling libusb_detach_kernel_driver() again is a means to
fix this.

Could you please take this upstream?

Thank you very much!

Cheers,

Fabian


signature.asc
Description: This is a digitally signed message part

Bug#791766: /usr/lib/cups/backend-available/usb: USB backend eats 100% CPU

[Fabian Greffrath]

Am Donnerstag, den 09.07.2015, 14:11 +0100 schrieb Brian Potkin:
> The word "sometimes" isn't one which brings joy to the heart when bug
> hunting. :)

Yes, I know, sorry. It is also confusing for me. As I wrote in one of
my later follow-ups, if I "killall -9 usb" the backend, the next
printing attempt may work without a flaw. thus, I suspect something
like a race condition as the culprit.

> How ofter does this happen? Has it just appeared with cups 2.0.3?

No, it also happened with cups 1.x. I just didn't find the time and
nerves to report the bug, because - just as you said - "it sometimes
dosn't work" isn't a good bug description to start with. ;)

> > ioctl(15, USBDEVFS_CLAIMINTERFACE, 0x7fffad353bfc) = -1 EBUSY 
> > (Device or resource busy)

I believe that the code which causes this is the following in
backend/usb-libusb.c:1515:

  while ((errcode = libusb_claim_interface(printer->handle, number1)) < 0)
  {
if (errcode != LIBUSB_ERROR_BUSY)
{
  fprintf(stderr,
  "DEBUG: Failed to claim interface %d for %04x:%04x: %s\n",
  number1, devdesc.idVendor, devdesc.idProduct, strerror(errno));

  goto error;
}
  }

So, what it does is trying to claim the interface and if the error code
isn't LIBUSB_ERROR_BUSY it busts out. But what if the error code
actually is LIBUSB_ERROR_BUSY? then the code is dead-locked in this
loop and tries to claim the interface endlessly. I think this is what I
see on my system.

Well, it's not that easy. Actually, LIBUSB_ERROR_BUSY is only returned
if the USB interface is already claimed, e.g. by a kernel driver. This
is checked earlier in the code in line 1437: If the return value of
libusb_kernel_driver_active() is 1 then a kernel driver is active and 
libusb_detach_kernel_driver() is called. So, it should be impossible
for the interface to be already claimed when the code in line 1515 is
called. But, one never knows, and repeatedly calling
libusb_claim_interface() over and over again won't help if the culprit
is LIBUSB_ERROR_BUSY but this is never checked for.

Thus, I assume that the following patch might work, but i am not sure
yet, because, you know, it only happens "sometimes". ;)

--- a/cups-2.0.3/backend/usb-libusb.c
+++ b/home/greffrath/usb-libusb.c
@@ -1522,6 +1522,16 @@ open_device(usb_printer_t *printer,  /* I - Printer 
*/
 
   goto error;
 }
+else if ((errcode = libusb_detach_kernel_driver(printer->handle, 
printer->iface)) < 0)
+{
+  fprintf(stderr,
+  "DEBUG: Failed to detach \"usblp\" module from %04x:%04x\n",
+  devdesc.idVendor, devdesc.idProduct);
+
+  goto error;
+}
+
+sleep (1);
   }
 
  /*

I added a sleep(1) call to prevent this loop from eating up 100% cpu as
it currently does. Do you think you could carry this issue and my
suggested patch upstream?

Thank you very much already!

Cheers,

Fabian


signature.asc
Description: This is a digitally signed message part

Bug#791766: Info received (Bug#791766: Acknowledgement (/usr/lib/cups/backend-available/usb: USB backend eats 100% CPU))

[Fabian Greffrath]

Maybe I should have told you earlier:

The printer is a Kyocera FS-1120D

$ lsusb | grep -i kyocera
Bus 004 Device 017: ID 0482:0407 Kyocera Corp.

 $ sudo /usr/lib/cups/backend/usb
DEBUG: Loading USB quirks from "/usr/share/cups/usb".
DEBUG: Loaded 114 quirks.
DEBUG: list_devices
DEBUG: libusb_get_device_list=15
DEBUG2: Printer found with device ID: 
ID:FS-1120D;MFG:Kyocera;CMD:PCLXL,PostScript 
Emulation,PCL5E,PJL;MDL:FS-1120D;CLS:PRINTER;DES:Kyocera FS-1120D; Device URI: 
usb://Kyocera/FS-1120D?serial=Q5Y1358476
direct usb://Kyocera/FS-1120D?serial=Q5Y1358476 "Kyocera FS-1120D" "Kyocera 
FS-1120D" "ID:FS-1120D;MFG:Kyocera;CMD:PCLXL,PostScript 
Emulation,PCL5E,PJL;MDL:FS-1120D;CLS:PRINTER;DES:Kyocera FS-1120D;" ""


signature.asc
Description: This is a digitally signed message part

Bug#791766: Acknowledgement (/usr/lib/cups/backend-available/usb: USB backend eats 100% CPU)

[Fabian Greffrath]

> Please tell me how I can provide further information.

Fun fact: If I kill the offensive process by "sudo killall -9 usb",
another GNOME windows pops up and tells me that printing did not
succeed. If I restart printing from my application, then, it succeeds
without any further issues.

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#791766: /usr/lib/cups/backend-available/usb: USB backend eats 100% CPU

[Fabian Greffrath]

Package: cups
Version: 2.0.3-6
Severity: important
File: /usr/lib/cups/backend-available/usb

Hi there,

sometimes it happens that I print a file to a USB-attached printer
and instead of printing, the usb process eats up 100% cpu. Nothing
else happens, apart from some GNOME window popping up and asking if my
printer is actually connected. In fact, it is.

This is what strace says the offending process does all the time:

ioctl(15, USBDEVFS_CLAIMINTERFACE, 0x7fffad353bfc) = -1 EBUSY (Device
or resource busy)

This repeasts endlessly.

Please tell me how I can provide further information.

Cheers,

Fabian


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'experimental'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cups depends on:
ii  cups-client2.0.3-6
ii  cups-common2.0.3-6
ii  cups-core-drivers  2.0.3-6
ii  cups-daemon2.0.3-6
ii  cups-filters   1.0.69-1
ii  cups-ppdc  1.7.5-12
ii  cups-server-common 2.0.3-6
ii  debconf [debconf-2.0]  1.5.56
ii  ghostscript9.06~dfsg-2
ii  libavahi-client3   0.6.31-5
ii  libavahi-common3   0.6.31-5
ii  libc-bin   2.19-18
ii  libc6  2.19-18
ii  libcups2   2.0.3-6
ii  libcupscgi12.0.3-6
ii  libcupsimage2  2.0.3-6
ii  libcupsmime1   2.0.3-6
ii  libcupsppdc1   2.0.3-6
ii  libgcc11:5.1.1-12
ii  libstdc++6 5.1.1-12
ii  libusb-1.0-0   2:1.0.19-1
ii  lsb-base   4.1+Debian13+nmu1
ii  poppler-utils  0.26.5-2
ii  procps 2:3.3.10-2

Versions of packages cups recommends:
ii  avahi-daemon 0.6.31-5
ii  colord   1.2.1-1+b2
ii  cups-filters [ghostscript-cups]  1.0.69-1
ii  printer-driver-gutenprint5.2.10-3

Versions of packages cups suggests:
pn  cups-bsd   
pn  cups-pdf   
ii  foomatic-db-compressed-ppds [foomatic-db]  20150411-1
ii  hplip  3.14.6-1+b2
ii  printer-driver-hpcups  3.14.6-1+b2
ii  smbclient  2:4.1.17+dfsg-4
ii  udev   221-1

-- debconf information:
  cupsys/raw-print: true
  cupsys/backend: lpd, socket, usb, snmp, dnssd


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150708100157.18356.50357.report...@kff50.ghi.rwth-aachen.de

Bug#788048: Acknowledgement (cups-filters: please request the generic monospace font alias from fontconfig instead of the hard-coded FreeMono)

[Fabian Greffrath]

Sorry, the patch is reversed, but you get the point...

- Fabian



signature.asc
Description: This is a digitally signed message part

Bug#788048: cups-filters: please request the generic monospace font alias from fontconfig instead of the hard-coded FreeMono

[Fabian Greffrath]

Package: cups-filters
Version: 1.0.68-1
Severity: normal
Tags: patch

Hi again,

cups-filters uses fontconfig to find a suitable monospaced font for
rendering text to pdf. However, this font is currently hard-coded to
FreeMono. This means, that if the FreeMono font package is installed, users
have no chance to change the font used for text rendering by means of
fontconfig rules anymore. FreeMono will *always* be preferred, there
is no choice.

By changing the hard-coded request for FreeMono to the generic
"monospace" alias, fontconfig returns the next best suitable monospaced font
that is available on the system. This might be FreeMono or any other
font. The actual preference of fonts, however, can be configured
per-system by means of fontconfig configuration files, which is the true
advantage of this approach.

The attached patch does exact this. Please consider applying it.

Thanks,

Fabian


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'experimental'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cups-filters depends on:
ii  bc 1.06.95-9
ii  cups-filters-core-drivers  1.0.68-1
ii  ghostscript9.06~dfsg-2
ii  libc6  2.19-18
ii  libcups2   1.7.5-11
ii  libcupsfilters11.0.68-1
ii  libcupsimage2  1.7.5-11
ii  libfontconfig1 2.11.0-6.3
ii  libfontembed1  1.0.68-1
ii  libgcc11:5.1.1-7
ii  libijs-0.350.35-10
ii  liblcms2-2 2.6-3+b3
ii  libpoppler46   0.26.5-2
ii  libqpdf13  5.1.2-2
ii  libstdc++6 5.1.1-7

Versions of packages cups-filters recommends:
ii  colord  1.2.1-1+b2

Versions of packages cups-filters suggests:
ii  foomatic-db-compressed-ppds [foomatic-db]  20150411-1

-- no debconf information
diff --git a/pdf.utf-8~monospace b/pdf.utf-8
index 1280f25..c1c3d68 100644
--- a/pdf.utf-8~monospace
+++ b/pdf.utf-8
@@ -28,5 +28,5 @@ charset utf8
 # printing.
 #
 
- 04FF ltor single monospace monospace:bold monospace:oblique monospace:bold:oblique
-0500 05FF rtol single monospace
+ 04FF ltor single FreeMono FreeMono:bold FreeMono:oblique FreeMono:bold:oblique
+0500 05FF rtol single FreeMono

Bug#788046: cups-filters: ships obsolete symlinks in /usr/share/cups/fonts

[Fabian Greffrath]

Package: cups-filters
Version: 1.0.68-1
Severity: normal

Hi there,

the cups-filters package still ship symlinks in /usr/share/cups/fonts
which point to font files in the fonts-freefont-ttf package. However,
since cups-filters uses fontconfig to find the best suitable
monospaced font, usage of FreeMono is not hard-coded anymore and these
symlinks do not serve any purpose anymore. Actually, if the
fonts-freefont-ttf package is not installed these symlinks are even
dangling.

Please consider removing the symlinks to reflect the fact that
fontconfig has taken over control of selecting an appropriate
monospaced font for texttopdf printing.

Thanks,

Fabian


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'experimental'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cups-filters depends on:
ii  bc 1.06.95-9
ii  cups-filters-core-drivers  1.0.68-1
ii  ghostscript9.06~dfsg-2
ii  libc6  2.19-18
ii  libcups2   1.7.5-11
ii  libcupsfilters11.0.68-1
ii  libcupsimage2  1.7.5-11
ii  libfontconfig1 2.11.0-6.3
ii  libfontembed1  1.0.68-1
ii  libgcc11:5.1.1-7
ii  libijs-0.350.35-10
ii  liblcms2-2 2.6-3+b3
ii  libpoppler46   0.26.5-2
ii  libqpdf13  5.1.2-2
ii  libstdc++6 5.1.1-7

Versions of packages cups-filters recommends:
ii  colord  1.2.1-1+b2

Versions of packages cups-filters suggests:
ii  foomatic-db-compressed-ppds [foomatic-db]  20150411-1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150608053555.1070.40589.reportbug@kff50

Bug#735223: cups-filters: Does not need to depend on specific fonts anymore

[Fabian Greffrath]

Package: cups-filters
Version: 1.0.43-1
Severity: minor

Hello,

for quite some time the cups-filters package uses fontconfig and does thus
depend on the libfontconfig1 package. This package depends on fontconfig-
config, which in turn does already depend on a reasonable selection of fonts -
i.e. packages which contain font families that provide all the sans, serif and
monospace flavors. It is thus not necessary anymore for the cups-filters
package to maintain its own list of font packages as dependencies.

 - Fabian



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (900, 'unstable'), (800, 'experimental'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages cups-filters depends on:
ii  bc1.06.95-8
ii  fonts-dejavu  2.33+svn2514-3
ii  fonts-liberation  1.07.3-3
ii  ghostscript   9.05~dfsg-8+b1
ii  libc6 2.17-97
ii  libcups2  1.6.4-2
ii  libcupsfilters1   1.0.43-1
ii  libcupsimage2 1.6.4-2
ii  libfontconfig12.11.0-2
ii  libfontembed1 1.0.43-1
ii  libgcc1   1:4.8.2-12
ii  libijs-0.35   0.35-8
ii  liblcms2-22.2+git20110628-2.3+b1
ii  libpoppler19  0.18.4-10
ii  libqpdf13 5.1.0-1
ii  libstdc++64.8.2-12

Versions of packages cups-filters recommends:
ii  colord  1.0.5-1

Versions of packages cups-filters suggests:
ii  foomatic-db-compressed-ppds [foomatic-db]  20131129-2

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140113211804.21402.37916.report...@kff50.ghi.rwth-aachen.de

Bug#726703: cups-filters: Please change Depends: ttf-dejavu to fonts-dejavu

[Fabian Greffrath]

Package: cups-filters
Version: 1.0.34-3+b1
Severity: minor

Hi,

the ttf-dejavu package name has been changed to fonts-dejavu. Please update the
alternative dependencies for the cups-filters package accordingly.

Thanks,

 - Fabian



-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (990, 'stable'), (900, 'unstable'), (700, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages cups-filters depends on:
ii  bc1.06.95-8
ii  fonts-liberation  1.07.3-3
ii  ghostscript   9.05~dfsg-8
ii  libc6 2.17-93
ii  libcups2  1.6.3-1
ii  libcupsfilters1   1.0.34-3+b1
ii  libcupsimage2 1.6.3-1
ii  libfontconfig12.10.2-2
ii  libfontembed1 1.0.34-3+b1
ii  libgcc1   1:4.8.1-10
ii  libijs-0.35   0.35-8
ii  liblcms2-22.2+git20110628-2.2
ii  libpoppler19  0.18.4-8
ii  libqpdf13 5.0.0-2
ii  libstdc++64.8.1-10
ii  ttf-dejavu2.33+svn2514-3

Versions of packages cups-filters recommends:
ii  colord1.0.2-1
ii  foomatic-filters  4.0.17-1
ii  ghostscript-cups  9.05~dfsg-8

Versions of packages cups-filters suggests:
ii  foomatic-db-compressed-ppds [foomatic-db]  20130912-1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131018080947.21846.58264.report...@hit-nxdomain.opendns.com

Bug#721521: ITP: fonts-urw-base35 -- Set of the 35 PostScript Language Level 2 Base Fonts

[Fabian Greffrath]

Package: wnpp
Severity: wishlist
Owner: Fabian Greffrath 

* Package name: fonts-urw-base35
  Version : 2:20130628-1
  Upstream Author : (URW)++ Design & Development
* URL : http://downloads.ghostscript.com/public/fonts/
* License : GPL (needs clarification, see #720906)
  Programming Lang: fonts
  Description : Set of the 35 PostScript Language Level 2 Base Fonts
 A commercial-quality set of the basic 35 PostScript Type 1 fonts.
 Each font includes .pfb (outlines), .afm (metrics), and .pfm (Windows printer
 metrics) files. The fonts are compatible with general Type 1 manipulation
 tools as well as with Ghostscript.

This package will contain an updated set of the 35 PostScript base fonts, that
has been made available by upstream author URW++ to Artifex, the developers of
Ghostscript, and is already shipped as part of ghostscript 9.09. It is intended
to replace the gsfonts package, which contains a fork of an ancient version of
these fonts with added cyrilic glyphs. However, that fork is long unmaintained
upstream and the glyphs are of reportedly questionable quality, which I cannot
judge for myself, though. The package will also integrate the effort to make
the fonts available to an X server and thus replace the gsfonts-x11 package.
Finally, I am going to convince the texlive maintainers to replace their copy
of these fonts in the texlive-fonts-recommended package (used for the psnfss
latex-package) with this pristine release. All corresponsing package
maintainers are in CC.

I am going to maintain this package under the umbrella of the pkg-fonts team.
The license for the fonts used to be GPL, but a corresponding note has
apparently been forgotten in the current release. This issue is reported as
#720906 in Debian (against the ghostscript package, which already ships an
updated version of these fonts, but not yet this latest update) and has been
brought to the attention of ghostscript upstream who will strive for
clarification with URW++ in the short term.

 - Fabian


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130901150636.9202.70922.report...@hit-nxdomain.opendns.com

Bug#496070: [ghostscript] opentypefont

[Fabian Greffrath]

Am Mittwoch, den 28.08.2013, 17:27 +0200 schrieb Jonas Smedegaard: 
> Yes, I am aware of that.  I thought we were in consensus about that.
>   
> The list I provided in my last email was meant as a starting point for 
> eventual exploration of *other* uses than for RIPs.  I.e. as a response 
> to the question about visual comparison.

Alright, that wasn't clear to me.

> There are several common practices.  Most (if not all) content of 
> poppler-data package has Adobe as true source (and is included with 
> Ghostscript project too, just stripped from recent Debian packaging).

I'll ask upstream what they consider an appropriate package name for the
fonts.

- Fabian


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1377760796.22018.14.ca...@kff50.ghi.rwth-aachen.de

Bug#496070: [ghostscript] opentypefont

[Fabian Greffrath]

Am Mittwoch, den 28.08.2013, 10:27 +0200 schrieb Jonas Smedegaard: 
>   f) GUS TeX Gyre: unknown base 35 match, covers eastern european, GFL.

Tex-gyre decided to sacrifice strict metric compatiblity with the Adobe
fonts in favor of nicer aesthetics, e.g. 

http://www.gust.org.pl/projects/e-foundry/tex-gyre/heros/readme-tex-gyre-heros.txt/view
 .

Thus, they may be preferable for type setting but are also unacceptable
for usage in ghostscript.

> For Postscript RIPs (Ghostscript and Poppler), base 35 match and GPL 
> compatibility is important.  I trust the Ghostscript project in picking 
> e) as the best option for that, and we should package their pick in 
> Debian (but IMO not branded as "Ghostscript pick", but "URW++ work"!).

e) is already part of ghostscript 9.09, though the font file names and
the font names in these files have been modified.

> For usees with TeX, especially if we want to try convince upstream to 
> align with us, we need to take into account the licensing.  TeXLive is 
> licensed as LPPL, and whereas the initially freed URW++ work was later 
> licensed also as LPPL, the newer works is maybe not.

Last time I asked, upstream seemed a bit stubborn about this issue and
there is also still a reply pending when I informed him about the
presence of the updated fonts last week. But I think we can convince the
Debian texlive maintainers to replace their font copies with symlinks to
the new urw fonts. Regarding the license, does everything in textlive
have to be under the LPPL or don't they also include stuff licensed
under the GPL?

> Seems you did such searches without quoting or other hinting, which
> only 
> (roughty) tells the amount of hits with _either_ of those search
> terms.

It's a weak measure anyway. We should (try to) stick to how upstream
calls them.

> Do you have a reference to URW++ naming, or did you assume their
> naming 
> from names of zip files redistributed by the Ghostscript project?

I was assuming from the names of the zip files they supplied to Artifex.

> I lost you here.  Seems you took my quote out of its context and make 
> similar point as I did.

Sorry if I was confusing. I just meant to say that it's already practice
that supplementary data which is neither affiliated nor restricted to a
speficic software but redistributed by the same project is called after
that project. I didn't know that you consider the package name
"poppler-data" also wrong, although upstream has chosen this name
itself.

- Fabian


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1377696359.11931.17.camel@kff50

Bug#496070: [ghostscript] opentypefont

[Fabian Greffrath]

Am Dienstag, den 27.08.2013, 18:11 +0200 schrieb Jonas Smedegaard: 
> Whoops - I had you mixed up with Reinhard Tartler. Sorry!

So, you mean Reinhard talked about font duplication in the archive? I
doubt so, but I think that code duplication with regard to ffmpeg/libav
is an isue to him.

> It is not a single font name but a bundle, mimicking Postscript "base 
> 35" list.

You can find them refered to as either "base" or "core" fonts, sometimes
even as "standard" fonts. Google return 13 mio hits for "postscript 35
core fonts" and 24 mio hits for "postscript 35 base fonts" and 30 mio
for "ghostscript 35 standard fonts". However, urw refers to them as
"core35", Artifex refers to them as "base 35" [1], Adobe refers to them
as "Core Font Set" [2]. Do you know what the official name is?

[1] http://artifex.com/indexfont.htm
[2]
http://partners.adobe.com/public/developer/en/font/TN5609.PS3_Fonts.pdf

> ...or should we make a copy of the package called fonts-poppler?

Bad example, maybe. Indeed, poppler provides supplementary encoding data
in the "poppler-data" package. This data is in no way restricted to
poppler, it is provided by others for use with poppler and the poppler
project is the one who actually provides the data. See any parallels
with ghostscript and the urw fonts? "fonts-ghostscript", anyone? ;)

- Fabian


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1377676939.10566.20.camel@kff50

Bug#496070: [ghostscript] opentypefont

[Fabian Greffrath]

Am Mittwoch, den 28.08.2013, 08:47 +0200 schrieb Bastien ROUCARIES: 
> What do you think ?

No. texgyre fonts are not intended to replace the urw-base35 fonts for
ghostscript. They merely provide added glyphs and better kerning for
LaTeX and in the form of the OTF variants for other applications as
well. 

Regarding falling back to texgyre fonts whenever an application requests
a base35 font via fontconfig: This is already taken care of, c.f.
#616419. It is just that Jonas recently found out that fontconfig might
still give the original urw fonts higher priority, but this is already
addressed in #720953.

- Fabian


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1377676235.10566.10.camel@kff50

Bug#496070: [ghostscript] opentypefont

[Fabian Greffrath]

Am Dienstag, den 27.08.2013, 18:11 +0200 schrieb Jonas Smedegaard: 
> How about package name fonts-base35-urw?  That indicating both a) the 
> aim of the bundle and b) the owner/maintainer of it.

We actually have a font packaging policy:

https://wiki.debian.org/Fonts/PackagingPolicy

So, the foundry has to come first in the package name. Artifex calls the
fonts artifex_core35 on their download page, so I think I'd prefer
"fonts-urw-core35", but "-base35" should be alright as well.

> Both urw and ghostscript are used: 
> http://rpmfind.net/linux/rpm2html/search.php?query=ghostscript-fonts 
> http://rpmfind.net/linux/rpm2html/search.php?query=urw-fonts

That's interesting! The former package contains fonts from the GNU
ghostscript fork whereas the latter contains the fork with added cyrilic
glyphs. Neither of them contains the pristine URW fonts or the ones
shipped by ghostscript itself.

> Yes, I got that confirmed upstream now too.  I want to test a bit first, 
> but will probably drop those fonts from Debian packaging of Ghostscript 
> (also strip them from source, to sidestep bug#720906).

Cool, that would be at least one copy less, only two more to go (though
it will get hard to convince the LaTeX maintainers to replace their copy
with the updated set from ghostscript).

- Fabian


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1377622455.8670.7.camel@kff50

Bug#496070: [ghostscript] opentypefont

[Fabian Greffrath]

[Resent to include the bug report.]

Am Dienstag, den 27.08.2013, 10:08 +0200 schrieb Jonas Smedegaard: 
> Yes, I noticed your emails about that at the Ghostscript project earlier 
> this month, and also seem to recall you raising this IRL in New York.

This must have been someone different. As much as I'd love to, I have
never been in New York. ;)

> I don't like how the Ghostscript project stuff lots of things into their 
> project.  Specifically about the URW++ fonts they lack proper licensing 
> - also separately packaged in those zip files.  I filed bug#720906 and 
> emailed the Ghostscript project about that yesterday.

That's indeed an issue, but I believe it can be sorted out rather
quickly.

> Those URW++ fonts - now that they are cleaned up - are better tracked 
> directly from URW++, in my opinion.  Yesterday I sent an email to URW++ 
> asking them for a download URL.

I exchanged some mail with an exmployee from Artifex, the developers of
Ghostscript, and he told me that URW's interest in maintaining these
fonts converges towards zero. They even had to pay them for the update
to the fonts that got shipped with 9.09.

> So generally I agree with your plan - just would prefer fonts-urw++ 
> instead of fonts-ghostscript.

Na, URW ist the foundry, not the font name. Fedora, for example, calls
the package ghostscript-fonts. I think we could call it fonts-urw
++-ghostscript, but since there are no other ghostscript fonts from
other foundries available in Debian we should better drop the foundry
part and simply call it fonts-ghostscript. I believe that's the most
expected and plausible package name.

> I totally agree we should get rid of code copies.  I have hesitated 
> dropping them for now, as I am afraid some internal Ghostscript code 
> might bypass the font path and rely on the specific location.
> 
> Hm.  I am now at the #ghostscript irc channel, so will simply ask... :-)

According to my contact at Artifex, ghostscript relies on the font file
names for its internally used fonts, but even those can be mapped to any
other font file by means of a config file in fontmap.d.

- Fabian


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1377613380.5218.0.ca...@kff50.ghi.rwth-aachen.de

Bug#613912: Solved upstream

[Fabian Greffrath]

Am Freitag, den 27.07.2012, 20:38 +0200 schrieb Bastien ROUCARIES:
> Since version 9.05 ghostscript ship official URW++ fonts, instead of modified.

That's great news, thanks for the heads-up!

> After the freeze we could work to solve this issue.

Yes, I am already looking forward to it.

 - Fabian


-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1343414664.20101.0.camel@debian

Bug#613912: ghostscript ships its own fonts in libgs9-common, additionally depends on gsfonts

[Fabian Greffrath]

Am Freitag, den 18.02.2011, 12:51 +0100 schrieb Jonas Smedegaard:
> That's what I am talking about: The Ghostscript project includes all 
> needed resources as part of a single tarball instead of as isolated 
> chunks.

Indeed, I understood your initial response the other way round. ;)

> Debian has a different objective.  And I believe it is better to track 
> them as a separate entity - a separate upstream project.  Even if it 
> might turn out that the current canonical upstream source for a while is 
> that same tarball which also holds Ghostscript.  Because that might very 
> well change again in the future!

There is a lot of motion currently in the thread that I sent you the
link to. Ghostscript is currently even considering reverting back to the
original URW++ fonts, but maybe they adopt the Text Gyre fonts or merge
the latest urwcyr release. We will see.

However, I think the fonts should be split into a separate package and
libgs9-common should depend on either this or gsfonts.

 - Fabian




-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1298149741.10639.9.camel@debian

Bug#613912: ghostscript ships its own fonts in libgs9-common, additionally depends on gsfonts

[Fabian Greffrath]

Am 18.02.2011 11:33, schrieb Jonas Smedegaard:

There are multiple reasons, e.g. historical packaging complications,
historical packaging cleanup complications, and the fact that upstream
treat external codebases as local sources, the latter causing
additional burden of our side of analysing and ripping apart the
various parts again.


Not anymore. IIRC starting with Ghostscript 8.60 (i.e. the one that 
combined the AFPL, GPL and ESP versions) the ghostscript release 
tarball also included the fonts in Ressource/Font (the ones that were 
only available as a separate download before). So strictly speaking, 
this was the moment when one of both font sets became obsolete.



I agree, however, with the message between the lines of your question:
There is no _sensible_ reason :-)


There is currently a discussion on gs-devel to merge the urwcyr 
1.0.7pre44 fonts that Debian ships in their gsfonts package into the 
fonts that ghostscript ships: 



So maybe this problem is solved upstream and Debian can finally stop 
shipping two slightly different font sets in its ghostscript and 
gsfonts packages.



So thanks for pointing this out! It is indeed a bug.


;)

 - Fabian



--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d5e4d6d.2030...@greffrath.com

Bug#613912: ghostscript ships its own fonts in libgs9-common, additionally depends on gsfonts

[Fabian Greffrath]

Package: libgs9-common
Version: 9.01~dfsg-1
Severity: normal

Hi Jonas,

is there a reason why ghostscript ships its own fonts in
/usr/share/ghostscript/9.01/Resource/Font in the libgs9-common package but also
depends on the gsfonts package? The latter contains modified variants of the
exact same fonts with added glyphs under different file names. Is it really
necessary to have both font sets installed?

 - Fabian



-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (501, 'unstable'), (101, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110218090732.3025.88911.reportbug@vfrodo

Bug#496070: [ghostscript] opentypefont

[Fabian Greffrath]

Dear Valek,

thanks for your quick response.

Am 10.02.2011 13:34, schrieb Valek Filippov:

Unless you are going to add TrueType instructions, TTF version
generated automatically would look at best not better than Type1.


I don't know if the fault is at pango, fontconfig or libfreetype (or 
anything else involved in the font rendering stack), but I have tested 
myself with pango-view and the onscreen-rendering is vastly improved 
if the Truetype variant is selected instead of the Type1 one. For 
comparison I have posted images to the original bug report in Debian 
requesting the Truetype conversions: 



The other reason for the Truetype variant is that cups could finally 
print plain text with the original Courier, ne Nimbus Mono font. ;)



I believe there will be near no difference between SFDs I have and
ones you can save once open PFBs in Fontforge.


Generally you may be right, but I'd prefer if I could avoid this 
manual disassembly and rebuild the fonts from your original sfd files.



I think it could be pre45, but can't check right now -- my main
computer still disconnected. I will reach it on weekend and reply on
that one.


Great, thank you very much in advance!

 - Fabian



--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d53e979.2040...@greffrath.com

Bug#496070: [ghostscript] opentypefont

[Fabian Greffrath]

I have minimized my proposed debdiff and updated against the current 
package version in unstable.


diff -u gsfonts-8.11+urwcyr1.0.7~pre44/debian/changelog gsfonts-8.11+urwcyr1.0.7~pre44/debian/changelog
--- gsfonts-8.11+urwcyr1.0.7~pre44/debian/changelog
+++ gsfonts-8.11+urwcyr1.0.7~pre44/debian/changelog
@@ -1,3 +1,10 @@
+gsfonts (1:8.11+urwcyr1.0.7~pre44-4.2fab1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Add Truetype transformations of the ghostscript fonts (Closes: #496059).
+
+ -- Fabian Greffrath   Thu, 10 Feb 2011 10:18:19 +0100
+
 gsfonts (1:8.11+urwcyr1.0.7~pre44-4.2) unstable; urgency=high
 
   * Non-maintainer upload.
diff -u gsfonts-8.11+urwcyr1.0.7~pre44/debian/dirs gsfonts-8.11+urwcyr1.0.7~pre44/debian/dirs
--- gsfonts-8.11+urwcyr1.0.7~pre44/debian/dirs
+++ gsfonts-8.11+urwcyr1.0.7~pre44/debian/dirs
@@ -2,0 +3 @@
+usr/share/fonts/truetype/gsfonts
diff -u gsfonts-8.11+urwcyr1.0.7~pre44/debian/control gsfonts-8.11+urwcyr1.0.7~pre44/debian/control
--- gsfonts-8.11+urwcyr1.0.7~pre44/debian/control
+++ gsfonts-8.11+urwcyr1.0.7~pre44/debian/control
@@ -3,6 +3,7 @@
 Priority: optional
 Maintainer: Masayuki Hatta (mhatta) 
 Build-Depends: debhelper (>= 4.0.0), sharutils
+Build-Depends-Indep: fontforge-nox | fontforge
 Standards-Version: 3.8.0
 Uploaders: Torsten Landschoff 
 Homepage: http://www.ghostscript.com/
diff -u gsfonts-8.11+urwcyr1.0.7~pre44/debian/rules gsfonts-8.11+urwcyr1.0.7~pre44/debian/rules
--- gsfonts-8.11+urwcyr1.0.7~pre44/debian/rules
+++ gsfonts-8.11+urwcyr1.0.7~pre44/debian/rules
@@ -37,12 +37,14 @@
 	#$(MAKE)
 	#/usr/bin/docbook-to-man debian/gsfonts.sgml > gsfonts.1
 
+	fontforge -script debian/convert.pe --format ".ttf" *.pfb
+
 	touch build-stamp
 
 clean:
 	dh_testdir
 	dh_testroot
-	rm -f debian/*.pfb
+	rm -f debian/*.pfb *.ttf
 	rm -f build-stamp configure-stamp
 
 	# Add here commands to clean up after the build process.
@@ -61,6 +63,7 @@
 	install -m 644 $(CURDIR)/*.afm $(CURDIR)/debian/gsfonts/usr/share/fonts/type1/gsfonts
 	install -m 644 $(CURDIR)/*.pfb $(CURDIR)/debian/gsfonts/usr/share/fonts/type1/gsfonts
 	install -m 644 $(CURDIR)/*.pfm $(CURDIR)/debian/gsfonts/usr/share/fonts/type1/gsfonts
+	install -m 644 $(CURDIR)/*.ttf $(CURDIR)/debian/gsfonts/usr/share/fonts/truetype/gsfonts
 #	cd debian && uudecode *.uue
 #	install -m 644 debian/*.afm $(CURDIR)/debian/gsfonts/usr/share/fonts/type1/gsfonts
 #	install -m 644 debian/*.pfb $(CURDIR)/debian/gsfonts/usr/share/fonts/type1/gsfonts
only in patch2:
unchanged:
--- gsfonts-8.11+urwcyr1.0.7~pre44.orig/debian/convert.pe
+++ gsfonts-8.11+urwcyr1.0.7~pre44/debian/convert.pe
@@ -0,0 +1,58 @@
+#!/usr/bin/fontforge
+#
+# This script is taken from:
+# <http://fontforge.sourceforge.net/scripting-tutorial.html>
+#
+# Copyright (C) 2000-2006 George Williams
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are met:
+#
+# Redistributions of source code must retain the above copyright notice, this
+# list of conditions and the following disclaimer.
+#
+# Redistributions in binary form must reproduce the above copyright notice, this
+# list of conditions and the following disclaimer in the documentation and/or
+# other materials provided with the distribution.
+#
+# The name of the author may not be used to endorse or promote products derived
+# from this software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
+# WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+# EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
+# BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
+# IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+# POSSIBILITY OF SUCH DAMAGE.
+
+i=1
+format=".ttf"
+while ( i<$argc )
+  if ( $argv[i]=="-format" || $argv[i]=="--format" )
+i=i+1
+if ( i<$argc )
+  format = $argv[i]
+  if ( format!=".ttf" && format!=".otf" && \
+	  format!=".pfb" && format!=".svg" )
+	Error( "Expected one of '.ttf', '.otf', '.pfb' or '.svg' for format" )
+  endif
+endif
+  else
+Open($argv[i])
+if ( $order==2 && (format==".otf" || format==".pfb" ))
+  SetFontOrder(3)
+  SelectAll()
+  Simplify(128+32+8,1.5)
+  ScaleToEm(1000)
+elseif ( $order==3 && format==".ttf" )
+  ScaleToEm(2048)
+  RoundToInt()
+endif
+Generate($argv[i]:r + format)
+  endif
+  i = i+1
+endloop

Bug#496070: [ghostscript] opentypefont

[Fabian Greffrath]

Am 08.02.2011 15:32, schrieb Fabian Greffrath:

I have seen many bug reports in which people complained about
improperly rendered web pages that had their prefered font set to
either Helvetica of Nimbus Sans, which means that the type1 system
fonts are selected for display. I am not sure, but I believe that the
kerning information for these fonts are not taken into account in
these cases. With truetype fonts (which have the information of both
the afm and the pfb file compiled in by fontforge) this problem should
be solved, while still preserving the original shape of the font.


This is indeed the truth!

1) I have only the regular gsfonts package installed, fontconfig uses 
the Nimbus Sans L Type1 variant (.pfb extension) as a replacement for 
Helvetica:


$ fc-match Helvetica
n019003l.pfb: "Nimbus Sans L" "Regular"

2) I render an example text using pango-view and requesting the 
Helvetica font. The resulting PNG is attached to this email:


$ pango-view --font "Helvetica" --text "Zwölf Boxkämpfer jagen Viktor 
quer über den großen Sylter Deich." -o n019003l_pfb.png


3) Now I convert the Type1 font into Truetype format and copy the 
resulting ttf file into my ~/.fonts directory. Fontforge immediately 
prefers this one over the Type1 variant (mind the .ttf extension), so 
there is no further action neecssary on the fontconfig side:


$ fc-match Helvetica
n019003l.ttf: "Nimbus Sans L" "Regular"

4) Now I render the exact same text again:

$ pango-view --font "Helvetica" --text "Zwölf Boxkämpfer jagen Viktor 
quer über den großen Sylter Deich." -o n019003l_ttf.png


Please note the difference in hinting: It is completely messed up with 
the pfb variant and has vastly improved with the ttf variant.


We should provide the transformed fonts ASAP!

 - Fabian
<><>

Bug#496070: [ghostscript] opentypefont

[Fabian Greffrath]

Another argument for converting gsfonts to truetype:

Does FontForge read in the old kerning information from fonts?
This question needs to be broken down into cases:

[...]
PostScript Type1 fonts anywhere other than the Mac.
The kerning information is not stored in a Type 1 font file. 
Instead it is stored in a file with the same filename as the font file 
but with the extension ".afm". When FontForge reads a PostScript font 
it will check for an associated afm file, and if found will read the 
kerning information from it.


From: 

I have seen many bug reports in which people complained about 
improperly rendered web pages that had their prefered font set to 
either Helvetica of Nimbus Sans, which means that the type1 system 
fonts are selected for display. I am not sure, but I believe that the 
kerning information for these fonts are not taken into account in 
these cases. With truetype fonts (which have the information of both 
the afm and the pfb file compiled in by fontforge) this problem should 
be solved, while still preserving the original shape of the font.


Then we would only need fontconfig to select the truetype variant by 
default if unsure...


 - Fabian



--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d5153ea.1090...@greffrath.com

Bug#496070: [ghostscript] opentypefont

[Fabian Greffrath]

Am 08.02.2011 10:06, schrieb Bastien ROUCARIES:

It seems that freebsd have converted their fonts to ttf see
http://www.freebsdsoftware.org/x11-fonts/urwfonts-ttf.html


According to 
 
they did not convert them on their own, but used the fonts from 
.


However, the newer revisions of the fonts found in this directory are 
only available in type1 format and are AFAICT already included in 
Debian's gsfonts package.



And it seems that these fonts have also some fontforge source see also
another bug report.


Erm, which bug report?

Anyway, I think we should convert the well-maintained gsfonts from the 
Debian package using the script I proposed in my original bug report 
instead of relying on some third-party fontforge sources. That is, 
unless we find an even more actively maintained source for the fonts, 
e.g. texlive.



BTW do you care to co maintian this package  ?


Sure, why not. ;)

 - Fabian





--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d510b7b.8050...@greffrath.com

Bug#496070: [ghostscript] opentypefont

[Fabian Greffrath]

owner 496070 !
block 495598 by 496070
thanks

Am 07.02.2011 19:03, schrieb Bastien ROUCARIES:

Nevertheless could you explain why you need opentype fonts?


My main motivation back then was that cups needs a replacement for the 
Courier font in order to print plain text (#516335) and this font 
needs to be in truetype (not opentype) format. The cups maintainers 
decided for ttf-freefont exclusively (#495598), although I think this 
was a bad choice and prefer ttf-liberation or the original gsfonts 
instead. The latter, however, are only available in type1 format and 
this I why I asked to make them available in truetype format as well.


 - Fabian






--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d50f875.5090...@greffrath.com