Bug#747181: xpdf: too many warning messages
Thanks for the check. It sounds more poppler side. I just read this
email, but are you OK to reassign it to poppler?
Also it might be better to annotate a prefix like "poppler" in the error in
general - though it's a bit of a large change...
2021年9月17日(金) 22:30 Vincent Lefevre :
> On 2021-09-17 14:40:06 +0200, Vincent Lefevre wrote:
> > The warning comes from xpdf/SplashOutputDev.cc
> >
> > if (xMin - xt < t3Font->glyphX ||
> > yMin - yt < t3Font->glyphY ||
> > xMax - xt > t3Font->glyphX + t3Font->glyphW ||
> > yMax - yt > t3Font->glyphY + t3Font->glyphH) {
> > if (t3Font->validBBox) {
> > error(errSyntaxWarning, -1, "Bad bounding box in Type 3 glyph");
> > }
> > return;
> > }
>
> Actually it doesn't (commenting out this line doesn't change
> anything). Perhaps a bug in poppler, then, as it has similar
> code in poppler/SplashOutputDev.cc:
>
> if (xMin - xt < t3Font->glyphX || yMin - yt < t3Font->glyphY || xMax -
> xt > t3Font->glyphX + t3Font->glyphW || yMax - yt > t3Font->glyphY +
> t3Font->glyphH) {
> if (t3Font->validBBox) {
> error(errSyntaxWarning, -1, "Bad bounding box in Type 3
> glyph");
> }
> return;
> }
>
> --
> Vincent Lefèvre - Web:
Bug#863382: xpdf: Config Error: Unknown config file command 'errQuiet'
This bug has been introduced in xpdf (3.04-6) with the changelog: * Hacks to compile with poppler 0.61 by Adrian Bunk (closes: #883523) I, however, wonder this patch is still valid or not, because I reverted comments for errQuiet related code and it worked well. I'll take a look at it more.
Bug#848631: Can I take over the xpdf package?
Svante, Thanks for your reply! I was sorry for the delayed response due to the holiday seasons. Yes, it seems poppler backend has been taken care of by Debian maintenairs, so I guess it's good to go. Enjoy your holidays, too! 2018年12月21日(金) 20:03 Svante Signell : > > Hi Manasori, > > I was never allowed to maintain that package since I wanted to use the > upstream backend. Debian requested that I should continue to support > the from xpdf upstream diverging poppler backend. > > As I see xpdf with the poppler backend is already maintained by the > Debian QA Group . Latest version is 3.04-12 > released 17 Dec 2018. From the changelog file names as Gianfranco > Costamagna, Iain Lane and others show up. And the latest version > carries your name! > > HTH! > > On Fri, 2018-12-21 at 18:51 +0900, Masanori Goto wrote: > > owner 848631 ! > > thanks > > > > Hi, I intend to adopt this package. Please let me know what you > > think. > > > > 2018年12月17日(月) 20:16 Masanori Goto : > > > > > > Hi Svante, > > > > > > It seems the package "xpdf" has been orphaned for 728 days, and I'm > > > happy to take the package maintenance. I continuously use this > > > package > > > so I don't want to lose this package from the support. > > > Can I take over the package maintener? > > > > > > Thanks, > > > -- gotom
Bug#848631: Can I take over the xpdf package?
owner 848631 ! thanks Hi, I intend to adopt this package. Please let me know what you think. 2018年12月17日(月) 20:16 Masanori Goto : > > Hi Svante, > > It seems the package "xpdf" has been orphaned for 728 days, and I'm > happy to take the package maintenance. I continuously use this package > so I don't want to lose this package from the support. > Can I take over the package maintener? > > Thanks, > -- gotom
Bug#848631: Can I take over the xpdf package?
Hi Svante, It seems the package "xpdf" has been orphaned for 728 days, and I'm happy to take the package maintenance. I continuously use this package so I don't want to lose this package from the support. Can I take over the package maintener? Thanks, -- gotom
Bug#873951: xpdf: new major upstream version 4.x
It sounds like the big question is whether we want to remove Motif version or not. If we want to continue to retain, we may want to have both (e.g.) xpdf-motif and xpdf-qt (and default is xpdf-qt). I personally think the only advantage of xpdf-motif (3.0.4) is speed - because it has a small footprint to start the app. Other than that, is there any other reason to keep having 3.0.4?
Bug#747181: xpdf: too many warning messages
Hi, Yes, xpdf shows many warnings, and adding "-q" command line option should make xpdf silent. Could you try it out? Thanks!
Bug#865120: release-notes: document i386/amd64 kernel changes for jessie->stretch
Recently I encountered this amd64 kernel issue on my i386 architecture machine. I think this is useful to be mentioned. Why don't we want to apply this proposed text? > You're quite right, this should have been documented. It might be > worth mentioning linux-headers-amd64 as well. Also, module-assistant > doesn't support foreign architectures but DKMS is fine. +1 to linux-headers-amd64. One tricky thing is, this is not officially supported so module-assistant doesn't work, so that should be clearly mentioned. I also had some issues to install some kernel related packages (e.g. virtualbox-dkms) so I'm not sure DKMS is fine or not - I rather think DMKS also doesn't work but I'd like to hear your feedback. Should we also mention that? Based on Justin's feedback, here's the change - who can pick up this documentation updates? Users are advised that the -amd64 flavor of kernel is no longer provided for the i386 architecture. Instead, these kernels are available and installed directly from amd64 architecture, using multiarch, the mechanism allowing the installation of foreign-architecture packages. To check if you are running i386 user space with amd64 kernel, run: dpkg --print-architecture; uname -r (would give i386 and a flavor ending in -amd64). To add amd64 as a foreign architecture, run: dpkg --add-architecture amd64; apt-get update (Install the appropriate kernel metapackage as described above.) Note that installing kernel modules are not officially supported through module-assistant.
Bug#850163: Any updates on this bugs?
Hi, I'm just curious, is there any update on this bug?
Bug#850163: xpdf fails to render Japanese text with various pdf files
Package: xpdf Version: 3.04-3 xpdf often fails to render pdf documents using Japanese fonts. This issue exists on Jessie, Stretch and the latest Sid. xpdf-i on Wheezy worked well as expected. Here's the procedure how to reproduce: > wget http://gum.debian.or.jp/2012/download/debian-gum-presentation.nojima.pdf .. > xpdf debian-gum-presentation.nojima.pdf Syntax Error: Missing language pack for 'Adobe-Japan1' mapping Syntax Error: Missing language pack for 'Adobe-Japan1' mapping Syntax Error: Unknown font tag 'F3' Syntax Error (4879): No font in show/space Syntax Error: Unknown font tag 'F3' Syntax Error (4917): No font in show/space Syntax Error: Unknown font tag 'F5' Syntax Error (4972): No font in show/space Syntax Error: Unknown font tag 'F5' Syntax Error (5005): No font in show/space Syntax Error: Unknown font tag 'F5' Syntax Error (5058): No font in show/space Syntax Error: Unknown font tag 'F5' Syntax Error (5074): No font in show/space Syntax Error: Unknown font tag 'F5' Syntax Error (5088): No font in show/space Syntax Error: Missing language pack for 'Adobe-Japan1' mapping Syntax Error: Missing language pack for 'Adobe-Japan1' mapping Syntax Error: Unknown font tag 'F3' Syntax Error (4879): No font in show/space Syntax Error: Unknown font tag 'F3' Syntax Error (4917): No font in show/space Syntax Error: Unknown font tag 'F5' Syntax Error (4972): No font in show/space Syntax Error: Unknown font tag 'F5' Syntax Error (5005): No font in show/space Syntax Error: Unknown font tag 'F5' Syntax Error (5058): No font in show/space Syntax Error: Unknown font tag 'F5' Syntax Error (5074): No font in show/space Syntax Error: Unknown font tag 'F5' Syntax Error (5088): No font in show/space
Bug#839677:
Control: tags -1 - pending I'm preparing for uploading a new version.
Bug#471021: locales: EastAsianAmbiguous character width is always 1 in UTF-8
It'd be great that you propose the good way to do so alternatively. 2009/1/11 d+...@vdr.jp: On Sun, Jan 11, 2009 at 11:17:48AM +0900, Masanori Goto wrote: wcwidth() is legacy function so that it cannot handle wide, RTL and combined characters correctly. An environment value to select its behavior is one way, but it's just a hack and it's hard to specify in libc. So, according to UAX#11 definition, it says we should return 1 for EastAsiasnAmbiguous characters unless a rigid signal (like language tag, script identification, associated font, source of data) is available in UTF-8. It's sure that we can introduce such kind of change for SJIS/EUC-JP, but it's hard to decide for ja_JP.UTF-8. Overall, we have no way to expand wcwidth() correctly and rightly, so I think each application should handle the actual font size of characters instead of using wcwidth(). Thank you for your explanation. I understand that unable to expand wcwidth() and each application should be modified. But each application implements each approach now For example, own one, various version of Markus Kuhn's wcwidth. In my layman's idea, could libc offer common method for it? Regards, dai -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#471021: locales: EastAsianAmbiguous character width is always 1 in UTF-8
wcwidth() is legacy function so that it cannot handle wide, RTL and combined characters correctly. An environment value to select its behavior is one way, but it's just a hack and it's hard to specify in libc. So, according to UAX#11 definition, it says we should return 1 for EastAsiasnAmbiguous characters unless a rigid signal (like language tag, script identification, associated font, source of data) is available in UTF-8. It's sure that we can introduce such kind of change for SJIS/EUC-JP, but it's hard to decide for ja_JP.UTF-8. Overall, we have no way to expand wcwidth() correctly and rightly, so I think each application should handle the actual font size of characters instead of using wcwidth(). 2009/1/9 d+...@vdr.jp: On Fri, Jan 09, 2009 at 01:56:20AM +0900, GOTO Masanori wrote: I don't agree with the concept of UTF-8-CJK because it's over exaggerated. Is it a locale dependent issue, or character encoding issue? I treat ``UTF-8-CJK'' locale as just workaround. Nothing could be better than using only UTF-8 locale. According to UAX#11, your point doesn't make sense because your reference just mention about character mapping. Instead, When processing or displaying data section says, Ambiguous characters behave like wide or narrow characters depending on the context (language tag, script identification, associated font, source of data, or explicit markup; all can provide the context). If the context cannot be established reliably, they should be treated as narrow characters by default. I see. If the all legacy applications use wcwidth() supposing the width of ambiguous font size = 2, it's OK to introduce your idea - but I'm not sure it's true or not. Font rendering application should basically consider the font size. Why doesn't rxvt consider about such font rendering size? Or should we introduce special environment variable or locale tag to decide the behavior of wcwidth value for ambiguous characters? For legacy applications' concern, it is good that selectable. If legacy applications are negligible, settled setting is better for users' convenience. But libc and locales are so fundamental, it is possible that its rigidity is a cause of concern... Regards, dai -- -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
