Re: Bug#481134: libpoppler does not use cmap files from xpdf-{japanese,...}, and fails to parse Japanese PDF files.

[Junichi Uekawa <dancer@netfort.gr.jp>]

Hi,


> > > 
> > > 1. poppler was theoretically self-contained, poppler-data was REJECTed
> > > once and not yet part of non-free as of today.
> > > 
> > > 2. Japanese users upgrading from etch would have xpdf-japanese
> > > installed because evince (poppler) needed and used xpdf-japanese, and
> > > natural upgrade path would be xpdf-japanese supporting poppler.
> > > 
> > > These factors make adding support in poppler somewhat reasonable.
> > 
> > If the release managers would approve an update to xpdf-japanese I am
> > happy to upload a new version including your patch, or for you to NMU
> > the package.
> > 
> 
> Which means the same should be done in
> xpdf-{chinese-{simplified,tranditional},korean} as well, and all will be
> unnecessary once poppler-data get accepted.  I kind of think that's not
> a good way to deal with it.  But well, just my 2 cents.

Yeah, which is why I'm a bit reluctant on fixing xpdf-japanese etc.
With additional upgrade path to poppler-data when it enters.


Getting poppler-data in for lenny should be much better: it's a new
random package in non-free which has little side-effect if added to
Debian archive.  

From the user's perspective, we probably want some
kind of documentation, since nothing pulls in poppler-data; users
expect working evince but they will be broken on upgrade until they
install poppler-data.



Looking forward into lenny+1, I think it's about time we start
thinking about adobe-cmap-xxx and xpdf-xxx and poppler-data unified in
some way; shipping similar files in multiple packages, and
dpkg-diverting patched files forever doesn't sound right.



regards,
	junichi
-- 
dancer@{netfort.gr.jp,debian.org}