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
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
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
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
*** 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
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
@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
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
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
(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
(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
Hi, the upstream info on this bug is a bit incorrect. Remmina moved to github,
so the sourceforge tracker doesn't appear to be used any more. I don't see a
corresponding bug logged in their new tracker:
https://github.com/FreeRDP/Remmina/issues
What's more, the code that's doing this isn't in Re
Sorry, should say that Bug #498911 is only related in that its another
.xsession-errors filling bug, but comment 11 contained info about /this/ bug,
specifically developer comments on this Remmina thread:
http://sourceforge.net/tracker/index.php?func=detail&aid=3315749&group_id=278330&atid=118167
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
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
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 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
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/33288
Title:
Ev
18 matches
Mail list logo
