Bug#1025660: xzgv: Exif Orientations 2 and 3 are handled incorrectly
Package: xzgv
Version: 0.9.2-2+b1
Severity: normal
Tags: upstream patch
When using xzgv with --exif-orient, not all orientations are handled
correctly.
Test Images can be found here:
https://github.com/recurser/exif-orientation-examples
Rotation 2 and 3 are not currently not rotated correctly by xzgv.
The exif rotation is translated into xzgv's internal representation in
backend_get_orientation_from_file(), here:
https://sourceforge.net/p/xzgv/git/ci/master/tree/src/backend.c#l215
static const ExifShort xzgv_orient[]={0,0,1,3,2,7,4,6,5};
The proposed fix is to swap the values at index 2 and 3, giving:
static const ExifShort xzgv_orient[]={0,0,3,1,2,7,4,6,5};
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (x86_64)
Kernel: Linux 5.19.0 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages xzgv depends on:
ii libc62.36-5
ii libexif120.6.22-3
ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1
ii libglib2.0-0 2.74.2-1
ii libgtk2.0-0 2.24.32-3
ii libx11-6 2:1.8.1-2
xzgv recommends no packages.
xzgv suggests no packages.
-- no debconf information
Bug#1019210: libxslt1.1: How to stop stderr log: "Attributed ... IDs for element, cleaned up ..."?
Package: libxslt1.1 Version: 1.1.35-1 Severity: minor On debian systems (but not other linux distributions / upstream libxslt!), use of libxslt can cause "secondary" log messages written to stderr, which are not redirectable via the usual xsltSetGenericDebugFunc / xsltSetGenericErrorFunc. It seems to come from here: https://sources.debian.org/patches/libxslt/1.1.35-1/0002-Make-generate-id-deterministic.patch/ AFAICT the information output by the fprintf is of _no_ relevance to ordinary users...(?) Can the fprintf be removed from the patch, or possibly hidden behind some conditional flag, for those that really need it? -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 5.19.0 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libxslt1.1 depends on: ii libc62.34-7 ii libgcrypt20 1.10.1-2 ii libxml2 2.9.14+dfsg-1+b1 libxslt1.1 recommends no packages. libxslt1.1 suggests no packages. -- no debconf information
Bug#939785: libxslt1.1: 1.1.32 prints "xsltReleaseLocalRVTs: Unexpected RVT flag (nil)" and sometimes produces broken xmls
Package: libxslt1.1 Version: 1.1.32-2.1 Severity: important The "xsltReleaseLocalRVTs" problem is fixed upstream in 1.1.33 (released in January), but debian still only provides 1.1.32. In the past I just ignored the spurious output, but now I've seen actually invalid xmls (broken UTF-8 encoding) produced by 1.1.32. With 1.1.29-5 things work fine. (Using Ubuntu's 1.1.33 .deb would require glibc 2.29, which is also not in debian yet.) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 4.18.0 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libxslt1.1 depends on: ii libc62.28-5 ii libgcrypt20 1.8.1-4 ii libxml2 2.9.4+dfsg1-7+b3 libxslt1.1 recommends no packages. libxslt1.1 suggests no packages. -- no debconf information
Bug#902051: libxslt: generate-id() not returning unique IDs
And the current patch has the additional problem, that *any* software that uses libxslt on debian systems will spuriously outputs warnings/errors(?) like (without any way to turn them off, it seems): "Attributed 3 IDs for element, cleaned up 0" which can mess up e.g. scripts that expects data on stderr only when some important problem has occured... Tobias
Bug#908922: xpp: deprecated cupsTempFile is used: printing stdin fails
Package: xpp Version: 1.5-cvs20081009-4 Severity: important When using xpp to print from stdin, e.g. via xpdf or simply using: $ cat my.pdf | xpp xpp fails with "Unable to create temporary file." when pressing the Print button. >From line 698 in https://sources.debian.org/src/xpp/1.5-cvs20081009-4/xpp.cxx/ it seems that cupsTempFile is used, which is deprecated and now always returns NULL. According to cups api doc, cupsTempFile2 or similar should be used. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 4.18.0 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xpp depends on: ii libc6 2.27-2 ii libcups22.2.6-4 ii libfltk1.1 1.1.10-25 ii libgcc1 1:8-20180312-2 ii libstdc++6 6.1.1-9 xpp recommends no packages. xpp suggests no packages. -- no debconf information
Bug#893819: systemd-shim: logind does not create a session, because systemd-shim does not create /init.scope like systemd does
Package: systemd-shim Version: 10-3 Severity: important Preface: Some software begins to depends on an existing logind-session. These sessions are created + tracked via libpam-systemd, which makes an dbus call to systemd-logind. systemd-shim it here to support logind, which replaces consolekit (AFAIUI) on systems where systemd is not the init process (i.e. pid 1). Problem: In auth.log: login[6880]: pam_systemd(login:session): Failed to create session: No such device or address The message belongs to -ENXIO, which is emitted here: https://github.com/systemd/systemd/blob/master/src/basic/cgroup-util.c#L1458 Result: $ loginctl SESSIONUID USER SEAT TTY 0 sessions listed. Expected result: $ loginctl [... some sessions ...] Root cause: $ systemd-cgls Control group /: -.slice ├─ 1 init [2] ├─1630 /lib/systemd/systemd-udevd --daemon ├─3661 /sbin/rpcbind -w [...] $ cat /proc/1/cgroup# or some other pid 4:name=systemd:/ [...] But since systemd 226 (AFAICT), all pids are moved (by systemd as init) into the /init.scope cgroup. In the systemd-shim case, systemd-logind still expects pid 1 and the pid of the login process to be in a such named cgroup - but fails, because everything is in the root slice (-.slice) and "nothing comes after the /". Evidence: $ mkdir /sys/fs/cgroup/systemd/init.scope $ echo 1 > /sys/fs/cgroup/systemd/init.scope/tasks # ... move login process (kdm/mingetty/...) there, too ... # e.g. by respawning mingetty on a particular tty, e.g. tty4 $ systemd-cgls # or: cat /proc/$PID/cgroup [... those two processes are indeed now in the new cgroup ...] Now login on that tty4, so that the login process is (resp. will be spawned in) the /init.scope cgroup. $ loginctl [...] 1 sessions listed. Required action: systemd-shim has to adjust the cgroups (using cgmanager?) accordingly for systemd-logind (and thus pam-logind) to succeed. Thank you. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 4.16.0-rc6 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd-shim depends on: ii cgmanager 0.41-2 ii libc6 2.27-2 ii libglib2.0-0 2.53.4-3 systemd-shim recommends no packages. Versions of packages systemd-shim suggests: ii pm-utils 1.4.1-9 -- no debconf information
Bug#663192: [Pkg-cups-devel] Bug#663192: cups-filters: Please add support for embedding of Opentype fonts
On 15/03/17 18:33, Brian Potkin wrote: 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? Cheers, Brian. Both types of fonts are fully usable and embedded into the PDF (i.e. the PDF is "selfcontained"). But only glyf-type fonts are subsetted, in other words: for CFF-type fonts the resulting PDF is not as small as it could be. For most fonts the size difference is probably in the lower 10 kB range. Tobias
Bug#763040: npm: npm help cmd is broken
Package: npm Version: 1.4.21+ds-2 Severity: normal npm help cmd is supposed to show the man page npm-cmd, but it only shows the list of more-or-less matching commands (which basically says: type npm help cmd to get more help). AFAIK, npm help install looks for /usr/share/npm/man/*/npm-install.1 but not for /usr/share/npm/man/*/npm-install.1.gz and as the former is not found by npm, npm help does not go on to call man npm-install (which would find the .gz file). According to http://anonscm.debian.org/cgit/pkg-javascript/npm.git/tree/debian/README.source the problem can be worked around by using appropriate symlinks, but the suggested links are not present in the debian package. Instead, /usr/share/npm/man itself is a symlink to /usr/share/man, where only .gz files are found. (Alternatively, npm could be patched to look for .gz man-pages, but this isn't currently done, either). -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 3.16.0-rc5-dirty (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages npm depends on: ii node-abbrev 1.0.4-2 ii node-ansi 0.3.0-2 ii node-ansi-color-table 1.0.0-1 ii node-archy0.0.2-1 ii node-block-stream 0.0.7-1 ii node-fstream 0.1.24-1 ii node-fstream-ignore 0.0.6-2 ii node-github-url-from-git 1.1.1-1 ii node-glob 3.2.6-1 ii node-graceful-fs 2.0.0-2 ii node-gyp 0.10.10-2 ii node-inherits 2.0.0-1 ii node-ini 1.1.0-1 ii node-lockfile 0.4.1-1 ii node-lru-cache2.3.1-1 ii node-minimatch0.2.12-1 ii node-mkdirp 0.3.5-1 ii node-nopt 3.0.1-1 ii node-npmlog 0.0.4-1 ii node-once 1.1.1-1 ii node-osenv0.0.3-1 ii node-read 1.0.4-1 ii node-read-package-json1.1.3-1 ii node-request 2.26.1-1 ii node-retry0.6.0-1 ii node-rimraf 2.2.2-2 ii node-semver 2.1.0-2 ii node-sha 1.2.3-1 ii node-slide1.1.4-1 ii node-tar 0.1.18-1 ii node-underscore 1.4.4-2 ii node-which1.0.5-2 ii nodejs0.10.25~dfsg2-2 npm recommends no packages. npm suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756736: libedit: UTF8 support still not working
Package: libedit2 Version: 3.1-20140620-1 Severity: normal File: libedit Although #737786 claims that libedit is now compiled with --enable-widec, the current debian version seems to be not. I can't even enter things like 'ä'. Also the library does not contain the symbols mentioned in the Ubuntu bug report #1276836. The git commit, which claims to close #737786, http://anonscm.debian.org/gitweb/?p=collab-maint/libedit.git;a=commit;h=8cb2a6c5706ad8fc034def186759eca4c2a2098c changes the changelog, but AFAICT does not contain any change to the actual configure invocation! -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 3.16.0-rc5-dirty (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libedit2:i386 depends on: ii libbsd00.4.0-1 ii libc6 2.17-97 ii libtinfo5 5.9-10 ii multiarch-support 2.13-35 libedit2:i386 recommends no packages. libedit2:i386 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687037: fmit: After long time pause tuner stops working
Package: fmit Version: 0.99.2-1 Severity: normal I often have fmit open in the background. I then use the pause function in the program. I've noticed (also with the previous version) that after a certain amount of time of pause (or possibly combined run+pause time?) unpausing will leave the program in an unusable state. Restarting fixes it; nevertheless this is annoying. Audio input is via jack. When fmit hangs the tuning dial does not respond any more, i.e. no note is estimated. But the program is NOT completely dead: The input meter and the captured sound display still work. Also the DFT view works, but all the other views don't. AFAIUI all the other non-DFT views depend on the note being estimated first (and e.g. the volume view displays the note in the lower left corner). Therefore I guess that some internal state related to the note-estimator breaks. I just found out that going to settings and simply pressing OK seems to make the program usable again. Still, this shouldn't be necessary. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.6.0-rc3-00072-gfc72098-dirty (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages fmit depends on: ii freeglut3 2.6.0-4 ii libasound21.0.25-4 ii libc6 2.13-35 ii libfftw3-33.3.2-3.1 ii libgcc1 1:4.7.1-2 ii libgl1-mesa-glx [libgl1] 8.0.4-2 ii libjack0 [libjack-0.116] 1:0.121.3+20120418git75e3e20b-2 ii libqt4-opengl 4:4.8.2-2+b1 ii libqtcore44:4.8.2-2+b1 ii libqtgui4 4:4.8.2-2+b1 ii libstdc++64.7.1-2 fmit recommends no packages. fmit suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687056: mitmproxy: fails with missing lxml
Package: mitmproxy Version: 0.8-1 Severity: important The mitmproxy program is not usable without also installing the python-lxml package, which is neither a dependency nor recommended nor suggested. mitmdump works without, though. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.6.0-rc3-00072-gfc72098-dirty (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mitmproxy depends on: ii python 2.7.3~rc2-1 ii python-imaging 1.1.7-4 ii python-openssl 0.13-2 ii python-pyasn1 0.1.3-1 ii python-urwid1.0.1-2 ii python2.6 2.6.8-0.2 mitmproxy recommends no packages. mitmproxy suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670055: cups-filters: diff for version 1.0.18-2 uploaded to DELAYED/2 for #670055
Paul Menzel wrote: As a side not Evince has problems displaying the output from CUPS-PDF. The text is not readable. Xpdf displays everything correctly though. So that issue is a separate bug in Evince I guess. Just more information. This seems to be a CUPS-PDF issue. $ pdffonts CUPS-PDF/test.pdf name type emb sub uni object ID - --- --- --- - [none] Type 3yes no yes 12 0 $ pdffonts /tmp/out.pdf name type emb sub uni object ID - --- --- --- - JMQJEJ+FreeMono CID TrueType yes yes no 11 0 But I think to remember, someone wrote in another bug report that CUPS-PDF is not meant for printing text. Still it is strange that Xpdf works fine. Ok. I've had another look. My emtpy PDF came from the very bug here reported (the fix is not in testing yet); I've copied my bzr build to the system folder, and voila...: Xpdf spits out a lot of Error: Bad bounding box in Type 3 glyph on the CUPS-PDF file. This is consistent with Type 3 in the font list. Evince-gtk does work here, BUT it prints: *** BUG *** In pixman_region32_init_rect: Invalid rectangle passed Set a breakpoint on '_pixman_log_error' to debug which probably causes empty pages in some other versions of evince and/or pixman/cairo. So why are Type 3 fonts used? I [22/May/2012:13:04:51 +0200] [Job 784] Started filter /usr/lib/cups/filter/texttopdf (PID 20424) I [22/May/2012:13:04:51 +0200] [Job 784] Started filter /usr/lib/cups/filter/pdftopdf (PID 20425) I [22/May/2012:13:04:51 +0200] [Job 784] Started filter /usr/lib/cups/filter/pdftops (PID 20426) I [22/May/2012:13:04:51 +0200] [Job 784] Started backend /usr/lib/cups/backend/cups-pdf (PID 20427) That means: Text is converted by texttopdf (fine). This is sent through pdftopdf (still ok). Then it is converted to PS by pdftops und converted back to PDF by cups-pdf (unwanted); also the font is converted to Type 3 by one of these two filters (not nice), but the routine outputs Type 3-bounding boxes the pdf consumer regards as wrong (bad), which is either a bug in the pdf consumer (poppler/...) or the producer (ghostscript for both pdftops and cups-pdf over here; pdftops(cups) seems to also be able to call pdftops(poppler-tools) which did not produce Type3 on a quick test...). If you gave me a hint where to assign such a report to, I would be very thankful. Hmm, I don't really know, but the cups-filters package has a bugtracker at https://bugs.linuxfoundation.org/ (under the OpenPrinting product). But just another debian bug would work equally well ... Till? Tobias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673289: Bug#670055: cups-filters: diff for version 1.0.18-2 uploaded to DELAYED/2 for #670055
Till Kamppeter wrote: Tobias, if this needs to be fixed in the texttopdf filter a bug on https://bugs.linuxfoundation.org/ can be filed. If it is a problem of Debian's packaging or Debian shipping a broken font or not shipping a required font then open a Debian bug. Well, it's still not clear, who should fix what: 1. cups-pdf should probably announce that it can not only process PS, but also PDF. I'm not sure if the current cups-filter architecture handles this case well. This bug would be one of cups-pdf or cups-filter(?). 2. It's unclear to me what the policy regarding pdftops is wrt. to using popper vs. ghostscript as converting agent. gs generates Type 3 (which causes problems), poppler does not. This can be fixed in pdftops, i.e. cups-filter, (use poppler tools in this case), or ghostscript (don't generate Type 3 -- there might be some commandline switches) 3. The issue, that the Type 3 bounding boxes generated by ghostscript are deemed bad by poppler/evince. The experts from ghostscript and poppler have to determine who is wrong (it might even be caused by the original font file). Therefore this is either a poppler/evince, ghostscript or font bug. I'm not sure if any of these points could even be worked around by texttopdf, i.e. no bug in textopdf, AFAICS. I don't have the spare time to take steps 1.-3. further myself, so if anyone would take over from here? Tobias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673289: Bug#670055: cups-filters: diff for version 1.0.18-2 uploaded to DELAYED/2 for #670055
Paul Menzel wrote: No it is not. I can no longer reproduce it. lpr -PCUPS-PDF-Printer /tmp/test.txt and CHARSET=utf-8 /usr/lib/cups/filter/texttopdf 1 user title 1 PageSize=A4 test.txt out.pdf work fine. As a side not Evince has problems displaying the output from CUPS-PDF. Does this mean the Evince problem also exists with out.pdf from above? The text is not readable. Xpdf displays everything correctly though. I can't reproduce that here; but for some reason my PDF-queue will treat text files as PS and invoke gs for PS-PDF conversion, which will result in an empty PDF even in xpdf. OTOH out.pdf from texttopdf (using FreeMono font) displays fine with xpdf and evince-gtk (3.2.1-1+b1) here. So that issue is a separate bug in Evince I guess. Might well be. What is known not to work is extracting text (i.e. pdftotext) from PDFs generated by texttopdf (there are some exceptions, thought). Tobias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673289: cups-filters: PID xxxxx (/usr/lib/cups/filter/texttopdf) crashed on signal 6.
First, please try 1.0.18-2 (which fixes #670055). If this does not help, do echo _ | CHARSET=utf-8 /usr/lib/cups/filter/texttopdf 1 user title 1 PageSize=A4 out.pdf or (with some in.txt) CHARSET=utf-8 /usr/lib/cups/filter/texttopdf 1 user title 1 PageSize=A4 in.txt out.pdf If this crashes without any output, it would help if you can provide a backtrace (preferably with debug symbols ...). Tobias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670055: cups-filters: diff for version 1.0.18-2 uploaded to DELAYED/2 for #670055
Till Kamppeter wrote: For me it looks OK, I would apply it upstream. Tobias, WDYT? Is this patch on texttopdf OK? Looks fine to me. Perhaps it also fixes bug 673289. I hope so... Tobias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673289: cups-filters: PID xxxxx (/usr/lib/cups/filter/texttopdf) crashed on signal 6.
On Thu, May 17, 2012 at 10:57 PM, Till Kamppeter till.kamppe...@gmail.comwrote: Paul, thank you for reporting the bug. Tobias, can you have a look into this? The crash is most probably caused by a font problem. Till
Bug#673289: cups-filters: PID xxxxx (/usr/lib/cups/filter/texttopdf) crashed on signal 6.
Tobias, can you have a look into this? The crash is most probably caused by a font problem. I currently have problems with my ISP... I will try to reproduce it at home, but I may need the newest packages. The filter can be run manually; this might give some hints, but unfortunately I don't have an appropriate commandline at hand here. Tobias
Bug#663192: [Pkg-cups-devel] Bug#663192: cups-filters: Please add support for embedding of Opentype fonts
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. Tobias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663192: [Pkg-cups-devel] Bug#663192: cups-filters: Please add support for embedding of Opentype fonts
Till Kamppeter wrote: Patches are welcome. Can OpenType be embedded in a PDF? Or would we need to convert such a font? We can and do embed SFNT-flavoured OTFs. I don't have the code ready to subset CFF-flavoured OTFs (but did some initial work some time ago [not under version control]). I will look into how we can at least provide full embedding for CFF. As I need metrics information from the font for texttopdf, this does require me to read at least some of the CFF formatted data -- which will need some work/time. My plan definitely is to support CFF eventually, as stated in the README of my so-called libfontembed. Are there any time constraints, like ASAP? Or could this wait a few weeks? Tobias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663192: [Pkg-cups-devel] Bug#663192: cups-filters: Please add support for embedding of Opentype fonts
Till Kamppeter wrote: There are not really time constraints. For Ubuntu Precise 12.04 cups-filters 1.0.5 with texttopdf being fully fontconfig-based is enough. Precise comes with suitable TTF fonts. Currently, the change is more thought for upstream to be prepared for the first distros which drop TTF fonts. Ok. I've looked a bit more into it now; the metrics are actually available in the usual form (hmtx-table). The only issue seems to be whether to only support PDF 1.6 (native OTF-CFF support), or also earlier versions, starting with PDF 1.2, which requires extraction of the CFF chunk (haven't looked at the details yet). Actually we currently claim PDF 1.3, but I'm not so sure, that I don't already use PDF1.6. features (libfontembed is called with EMB_DEST_PDF16 ...). I think that at least basic (non-subsetting) CFF support can/should be available and is easy enough to provide. At least PDF =1.6 support seems achievable in a reasonably short timeframe. Everything else can be added when there is an actual need. Tobias PS: The term SFNT-flavoured OTF in my previous message is rubbish; what I meant was glyf-flavoured. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
