Version: 0.9.1 (using KDE 4.3.1) OS: Linux Installed from: Gentoo Packages I created a PDF sample document (attached) which seems problematic when I'm using the copy-to-clipboard selection tool of okular. The copied text has a wrong order so the original meaning is lost. For instance, from the attached document I get the following text: 1. First chapter 2. Second chapter a) Section number one b) Section number two c) and three i. ok ii. two d) and four 3. Last chapter 1 10 11 18 22 23 30 40 100 which is of course in the wrong order.
Created attachment 37980 [details] test.pdf the problematic document
Created attachment 37981 [details] test.odt the source file used to create test.pdf
FYI, the order of the copied text is the order the text characters are stored in the PDF document.
I think that the user expects the data in the clipboard with the "visual" order (as with kpdf). Is there a chance that the data ordering will be changed? Maybe there could be a configuration option for choosing the behaviour of the operation.
> I think that the user expects the data in the clipboard with the "visual" order > (as with kpdf). The generic "block" selection (the only one available in KPDF) is still there. > Is there a chance that the data ordering will be changed? Maybe there could be > a configuration option for choosing the behaviour of the operation. What would adding a "configuration option" solve? This is a case much similar to bug #161324 (recognising logical text columns), ie the text information in the document are not in the "logical" order for reading, so there must text analysis for solving this "problem". (Also note that your testcase is a perfect example of what would be eventually considered as a two-column text flow.)
(In reply to comment #5) > The generic "block" selection (the only one available in KPDF) is still there. But it doesn't seem enabled in the GUI. The "selection tool" in okular behaves in a different way respect the "select tool" in kpdf. > ie the text information in the document are not in the "logical" order for > reading, so there must text analysis for solving this "problem". (Also note > that your testcase is a perfect example of what would be eventually > considered as a two-column text flow.) Does kpdf do some logical analysis on the text?
(In reply to comment #6) > (In reply to comment #5) > > The generic "block" selection (the only one available in KPDF) is still there. > > But it doesn't seem enabled in the GUI. The "selection tool" in okular behaves > in a different way respect the "select tool" in kpdf. Now I see; although, the PDF libraries used by KPDF and Okular are different in some extend, and Okular uses the Poppler library. > > ie the text information in the document are not in the "logical" order for > > reading, so there must text analysis for solving this "problem". (Also note > > that your testcase is a perfect example of what would be eventually > > considered as a two-column text flow.) > > Does kpdf do some logical analysis on the text? No. *** This bug has been marked as a duplicate of bug 168953 ***