A Dilluns, 16 de novembre de 2009, Baz va escriure: > 2009/11/15 Albert Astals Cid <aa...@kde.org>: > > A Divendres, 13 de novembre de 2009, Baz va escriure: > >> Hi, > >> I uploaded a new version of my multicolumn select patches to > >> https://bugs.freedesktop.org/show_bug.cgi?id=3188 this morning, as you > >> might've seen. This version uses a similar algorithm to ocropus to > >> determine reading order, and tries to make the selection follow this > >> reading order. Its looking fairly good now I think - for all but one > >> of the documents I tested with it picked a reasonable order, and > >> selection doesn't jump all over the place. Of course, I've only tested > >> on the handful of docs that were in the bug reports so I might've made > >> things worse elsewhere :( > >> > >> I was wondering what I can do to get these patches into an acceptable > >> state. There's some obvious issues still to iron out, eg RTL (see > >> http://bugs.kde.org/show_bug.cgi?id=156380 , > >> http://bugs.kde.org/show_bug.cgi?id=184399) and handling blocks with > >> non-zero rotation; also the new depth_first_visit method I added is in > >> the wrong class - should probably be in TextBlock. I'll fix this up. > >> > >> But beyond that, these patches might be problematic because they > >> remove the old selection behaviour. The new behaviour is much better > >> for multicolumn documents, but is likely to be worse at selecting data > >> out of tables, for example. Should the new selection mode introduce > >> new API, so as not to change the current behaviour of Evince & > >> Okular[1]? > > > > What was the [1] supposed to mean here? > > Typo. A reference to a footnote about me not using Okular that was > left over when I moved that into the text... ignore. > > > As Carlos said we use a Okular coded > > algorithm for text selection so i'm not sure should affect us much, on > > the other hand we still have the same problem with columns so if this > > work we should probably apply a similar solution to okular. > > Ok. > > >> In older versions of acrobat, they had 'table select' and > >> 'text select' modes, covering these two uses, but more recently table > >> select has been dropped entirely. I suspect that they now just follow > >> the tags in tagged pdf, with the fallback behaviour being something > >> like what I've coded up here. > >> > >> Also, testing. At the moment, testing for me consists of opening a > >> bunch of documents in Evince and selecting stuff randomly (I don't > >> have Okular, but since they use the same API for text selection I > >> presume the bug is the same). I have no idea if I'm introducing > >> regressions. Is there a plan to integrate the unit test framework that > >> was discussed previously? > >> http://lists.freedesktop.org/archives/poppler/2009-March/004535.html . > > > > The Qt4 frontend already has unittests, these are unit tests for glib > > frontend, not a test suite that is what you want. > > Ok, I see that now. The qt4 tests refer to documents that aren't in git > though?
Yes they are http://cgit.freedesktop.org/poppler/test/ Albert _______________________________________________ poppler mailing list poppler@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/poppler
