On Wed, Aug 20, 2008 at 04:06:40PM +0200, Loïc Minier wrote: > For the long term, I'd recommend either b), or c) if b) isn't possible; > for lenny, either the long term approach or the d) approach would work, > but d) would only solve the problem for this particular package. > > Because b, c), and d) will almost certainly require changes to > xpdf-japanese, I'm reassigning the RC counterpart of this bug to this > package. I'm keeping an important bug open against poppler because it > can be considered a regression of poppler, but I don't think it should > be considered RC for poppler because: > * xpdf-japanese is non-free while poppler is free; perhaps this is a > fallacy, but I don't think support for a non-free package should > affect the Debian release; if this is considered >= serious > severity, it shouldn't be release-blocking > * it's an upstream design decision that poppler doesn't support xpdf > config/data and poppler doesn't aim to be compatible with xpdf's > config/data: xpdf-japanese needs to grow compatibility with poppler > instead
Patches for xpdf-japanese would be most welcome. I'm not familiar with the details of fontconfig, defoma etc. Maybe the relevant data in xpdf-japanese should be moved into cmap-adobe-japan1 instead. Probably xpdf-japanese's additional CMaps should move too; I thought I submitted a bug about this years ago but I don't see it now. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
