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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
21 matches
Mail list logo
