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

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

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

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 te

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

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 kicke

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

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

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

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

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

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

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! T

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

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

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

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

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

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 p

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

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!

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

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 att

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

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

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

> 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

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

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 as

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

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

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

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

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 Fre

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

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. p

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

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

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

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,

Bug#496070: [ghostscript] opentypefont

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 t

Bug#496070: [ghostscript] opentypefont

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

Bug#496070: [ghostscript] opentypefont

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

Bug#496070: [ghostscript] opentypefont

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

Bug#496070: [ghostscript] opentypefont

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 foun

Bug#496070: [ghostscript] opentypefont

[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 muc

Bug#613912: Solved upstream

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. - Fabia

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

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 ha

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

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 r

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

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 f

Bug#496070: [ghostscript] opentypefont

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 anyth

Bug#496070: [ghostscript] opentypefont

/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

Bug#496070: [ghostscript] opentypefont

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

Bug#496070: [ghostscript] opentypefont

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 f

Bug#496070: [ghostscript] opentypefont

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 o

Bug#496070: [ghostscript] opentypefont

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 ne