evince should Suggests xpdf-japanese (or poppler-data when it'll be available)

Bug #48708 reported by Gustavo Carneiro
22
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ubuntu Japanese Kaizen Project
Fix Released
Undecided
Unassigned
evince (Ubuntu)
Fix Released
Wishlist
Unassigned

Bug Description

As I noted in [1], evince refuses to copy-paste from most PDF files (including one that I generated with OpenOffice2) because of the missing support for EUC-JP. Installing the package xpdf-japanese fixed the problem.

Give that copy-paste appears broken without it, shouldn't this package be a hard depedency of evince or libpoppler?

[1] https://bugs.freedesktop.org/show_bug.cgi?id=7129

Revision history for this message
Daniel Holbach (dholbach) wrote :

Thanks for your bug report. I would go for a recommends or a suggests.

Changed in evince:
assignee: nobody → desktop-bugs
status: Unconfirmed → Confirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :

I don't have xpdf-japanese installed and the example your pointed on the freedesktop bug seems to work fine and copy works fine on it too. Do you have any example to provide with some details on what is wrong exactly about it?

Changed in evince:
status: Confirmed → Needs Info
Revision history for this message
Sebastien Bacher (seb128) wrote :

I'm not sure that's a packaging bug as you pointed upstream, poppler and evince should not require xpdf to be installed to work correctly, if poppler needs that file shouldn't it ship a copy of it?

Revision history for this message
Gustavo Carneiro (gjc) wrote :

Then it's a poppler bug.

I tested it again, evince copy-paste definitely doesn't work the example I provided unless xpdf-japanese is installed.

Revision history for this message
Sebastien Bacher (seb128) wrote :

poppler-data is available upstream now to fix that. Those are data are non-free though (the copyright is to Adobe) so the evince package can't Depends on it. We will make evince (or libpoppler1 maybe) Suggests poppler-data when it'll be available

Changed in evince:
importance: Low → Wishlist
status: Needs Info → Confirmed
Changed in evince:
status: Confirmed → Triaged
Revision history for this message
Gustavo Carneiro (gjc) wrote :

IMHO it should be recommend or hard dep. Having copy-paste silently broken is not fun :(

Revision history for this message
Sebastien Bacher (seb128) wrote :

The issue is that those datas are non free so we can't Depends or Recommends them easily

Revision history for this message
ibotty (ibotty) wrote :

not only rendering, but also displaying is broken w/o poppler-data. say for this pdf: http://www.huettenhilfe.de/wp-content/uploads/kochbuch/Tapas-Kochbuch.pdf

Revision history for this message
Jeroen Hoek (mail-jeroenhoek) wrote :

I just ran into this issue (some Japanese PDF's not displaying their text in a legible fashion) again after having forgotten about for a year. The answer is right here in the bug tracker of course, but I don't think we should expect that the average user hunts down bug reports and mailing-lists for the answer to these kind of issues.

If depending or recommending isn't an option, are there other ways of telling the user he needs package X whenever this problem occurs?

Revision history for this message
ibotty (ibotty) wrote : Re: [Bug 48708] Re: evince should Suggests xpdf-japanese (or poppler-data when it'll be available)

> If depending or recommending isn't an option, are there other ways of
> telling the user he needs package X whenever this problem occurs?

packagekit might be the answer (analogous to e.g. totem for codecs).

Revision history for this message
Sebastien Bacher (seb128) wrote :

the language packs recommends poppler-data nowadays, closing the bug

Changed in evince (Ubuntu):
status: Triaged → Invalid
Revision history for this message
Rolf Leggewie (r0lf) wrote :

reopening.

I may well want to read a Japanese or Chinese PDF from time to time. That doesn't necessarily mean I have the language-pack installed. I'm sure we can do better than the current situation.

FWIW, acroread detects when there are glyphs in a PDF that it cannot properly display currently. Maybe that's a different option. I understand both approaches have drawbacks. I can't immediately present the most appropriate solution.

Changed in evince (Ubuntu):
status: Invalid → Triaged
Revision history for this message
Nobuto Murata (nobuto) wrote :

> the language packs recommends poppler-data nowadays, closing the bug

No, it does not yet.

$ apt-cache rdepends poppler-data
poppler-data
Reverse Depends:
  epdfview
  okular
  evince

There is no language-pack entry.

This is related Bug #530452.
MIR is not finished yet.
poppler-data is still in universe repository.

Changed in evince (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
Revision history for this message
Timmy Shih Jun Yee (shijun) wrote :

In Lucid, Evince suggests poppler-data, so I'm marking this bug as fixed.

Those who are interested in having Evince depend on poppler-data should have a look at bug 616321.

Changed in evince (Ubuntu):
status: Triaged → Fix Released
Fumihito YOSHIDA (hito)
Changed in ubuntu-jp-improvement:
status: New → Fix Released
Revision history for this message
quequotion (quequotion) wrote :

Marked as a duplicate, although this report is older and more original, the discussion on but #197537 has progressed more and is more recent.

This bug is not fixed.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.