[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#663192: marked as done (cups-filters: Please add support for embedding of Opentype fonts)

Your message dated Sat, 25 Mar 2017 18:14:16 +0000
with message-id <25032017180122.1bec6db11ceb@desktop.copernicus.org.uk>
and subject line Re: Bug#663192: [Pkg-cups-devel] Bug#663192: cups-filters: Please add support for embedding of Opentype fonts
has caused the Debian Bug report #663192,
regarding cups-filters: Please add support for embedding of Opentype fonts
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
663192: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663192
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: cups-filters
Version: 1.0.4-1
Severity: wishlist
Tags: upstream

Hi,

one might consider OpenType as the font format of the future.

As Debian is currently switching to format-independent package names for fonts,
re-evaluation of the best suitable font format is pending for many fonts
(since it will not make sense to package fonts in both TrueType and OpenType
formats). One of the main reasons to stay with the TrueType format for e.g. the
GNU FreeFont package is that it's still the prefered font for the texttopdf
filter and that it *must* be in TrueType format for this filter to be able to
embed it, c.f. <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662924#40>.

The same applies to the other fonts providing valid alternatives for the
Courier type, i.e. DejaVu and Liberation. We are bound to have those fonts in
TrueType format as long as the texttopdf filter is unable to embed OpenType
fonts. Once we switch the fonts to more enhanced font formats, they become
useless for the texttopdf filter.

 - Fabian



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

Kernel: Linux 3.1.0-1-686-pae (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

--- End Message ---
--- Begin Message --- 
On Wed 15 Mar 2017 at 17:33:24 +0000, Brian Potkin wrote:

> On Fri 16 Mar 2012 at 06:52:43 +0100, Tobias Hoffmann wrote:
> 
> > Ok, I've finally managed to push last weekend's work into bzr, for the
> > upcoming V1.0.6.
> > This means:
> > CFF-flavoured OTFs are now supported, but without subsetting, i.e. full
> > embedding is done (while glyf-type TTFs are properly subsetted).
> > I've done some cleanup/rework of the fontembed internals and fixed some
> > bugs, that came along my way;
> > The fontconfig selection in texttopdf now accepts both TTF and OTF fonts; I
> > also did some minor improvements.
> > Due to the rather large amount of touched code, new bugs might have crept in
> > -- please report.
> 
> 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?

Fabian and Tobias,

Thank you very much for such prompt and informative replies. It seems
to me that the essential essence of the enhancement request has been
fulfilled, so I will close this report.

Regards,

Brian.

--- End Message ---
Reply to: