(In reply to comment #70)
(I originally replied on launchpad, which is supposed to copy it through
to here, but it hasn't.)
Carlos: it isn't a regression that lines outside a rectangle formed by
the start and endpoints are included, it's the intent.
Consider selecting in a document with two colu
(oops, replied on launchpad, not sure if Carlos reads there. Repeating
for fdo)
Carlos: it isn't a regression that lines outside a rectangle formed by
the start and endpoints are included, it's the intent.
Consider selecting in a document with two columns, starting in the 1st
column 2/3 down the
Carlos: it isn't a regression that lines outside a rectangle formed by
the start and endpoints are included, it's the intent.
Consider selecting in a document with two columns, starting in the 1st
column 2/3 down the page, ending in the 2nd column 1/3 down the page. In
this case, the correct selec
Created attachment 40124
patch without extraneous whitespace changes
Oops! Ok, here's the patch without the whitespace changes.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/33288
Tit
Created attachment 40061
improved patch
Had another look and tidied the code a bit removing repeated page
orientation checks, and a redundant test for overlap in rule(2). This is
noticeably faster rendering the bus map. (down to ~14.8s)
--
You received this bug notification because you are a mem
Created attachment 40056
patch to fix performance regression
Here's what I've got so far. On my very slow VM, this renders the paris
bus map reported on the mailing list in ~15.2s, compared to ~60s without
the patch. YX-sorting alone got the time down to ~16.2s. Rendering on
other documents is as
It should be possible to improve this substantially. When I wrote the
patch I was being very conservative with the existing poppler data
structures, so essentially that method is traversing an unordered list.
If the block list was in isBeforeByRule1 order most of those comparisons
would go away. I
Mark: what's going on there is that the bounding boxes of the (1) (2)
(3) ... text regions are tightly around the text you can see, and when
the mouse is between them, its not over any text region at all. Hence,
the best guess of what you were trying to select is the nearest text
region (by manhatt
João - actually that's quite interesting - this side effect in Okular is
something I hadn't seen. Going back through my mails I see Carlos told
me:
"Okular doesn't use TextOutputDev for selecting, but it does for
extracting the text, so it will be affected anyway."
This is what you're seeing - Ok
Carlos has just pushed the patches upstream, but is leaving the bug open
for future work (so the status of the upstream bug 3188 won't appear to
change). Hopefully this improves the chances of them making it into
Lucid.
--
Evince doesn't handle columns properly
https://bugs.launchpad.net/bugs/332
@tpgraveen "any known regressions". What we're testing here is a
heuristic for what users want, there is no right answer. So yes, in some
cases the selection is "worse" (a specific example is dealing with
bullet lists that have come from TeX, they leave a very wide gap before
the list text and popp
Yes, I have had no time to work on/review this for a while now, for a
number of reasons. My calendar clears up a bit after Easter, hoping to
pick it up again then. However, its worth pointing out that the patches
as it stands are about as far as I want to push the current api (which
is based on sel
Wouter: I'll see what I can do, but it might be a while. I've never
built a PPA either (and had to look that up). I recently gave up on
using Gnome Dev Kit (Foresight Linux) for an Ubuntu 9 VM, so who knows,
there may be tools on that to help me. However, I don't have much time
to work on this and
I've uploaded an updated patch series to
https://bugs.freedesktop.org/show_bug.cgi?id=3188 , with corrections to
selection and reading order. Those of you who can apply these and
rebuild evince might want to give this a go? Comments over there please!
For me it fixes up selection for most (but not
*** This bug is a duplicate of bug 33288 ***
https://bugs.launchpad.net/bugs/33288
David - I believe this bug is the one you mentioned on bug 33288. Yes,
this is not quite a duplicate, but hopefully fixing that will help here
too.
The bug in 33288 is caused because the heuristic used to detec
David #19: you say "it perhaps recognizes column stuff from the display
layout instead of the internal representation."
In PDF, the internal representation *is* just the display layout.
Internally, poppler tries to divide this text into blocks (roughly
paragraphs) which are then grouped into colum
16 matches
Mail list logo
