<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Jauco, Sorry for the late reply, I just read through your mail and your blog and it looks like you've done some great work.  From the screenshots your text flow analysis looks really good, and my first though was that this will probably also be useful for text selection in pdf viewers.  The text flow analysis in TextOutputDev.cc is easily confused, which leads to weird behavior during selection, where the selection will jump around and suddenly include unrelated blocks of text from across the page (<a href="https://bugs.freedesktop.org/show_bug.cgi?id=4006" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> https://bugs.freedesktop.org/show_bug.cgi?id=4006</a>).</blockquote><div> hehehe, I'm not the fastest replyer myself...  sorry about that, I had a few weeks of extreme busyness combined with extreme tiredness/lazyness. But I'm ready to get rocking again :) </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'm thinking that your text flow analysis is a bit more robust and if we could use this as the basis for text selection too, we'd have a much better story there.  I don't know how much time you have to work on this now, but if you could split the text flow analysis from the abi word xml output, that would be great.  Ideally, we keep the flow analysis in poppler core ( i.e. in the poppler/  dir) and refactor the code to build up a data structure that represents the text flow (basically, just like TextOutputDev.cc does it).  Then the abiword output tool just traverses this data structure and output the xml document.  That way the libxml dependency also moves to the abiword tool instead of making libpoppler depend on it.  Once that's in place, I'd like to revisit the poppler selection code and see if I can make it use your text flow analysis.</blockquote> <div>I'm ok with dropping the dependency, but: My code works by constructing a tree based on x,y coordinates and then interpreting this tree as a reading order list of paragraphs. The construction of the tree is done in such a way that a flattened tree will be in correct reading order. If you only want a long string of text in correct order this might be doable without constructing the tree. I would need to take a good look at how it is done now to be sure. Without the tree there will be no way to define paragraph endings and other stuff I need for the structured text creation though. So that leaves two possibilities: Writing code to maintain a tree with attributes inside poppler or duplicating the code to the selection part and rewriting it there to create a flat list. I'm not a great fan of writing my own code to duplicate libxml functionality, I'll doubtlessly introduce new bugs and I have to serialise to xml eventually anyway. Anyway, great you like it! I'm finishing my internship ATM and doing some other assignments but I'm determined to get this code fixed for inclusion into poppler. Getting the text selection fixed would be scratching a major itch as well. (I need to copy-paste from pdf's a _lot_ :) So let me no which direction you think is the best for poppler as a whole. </div></div> -- greetings,      Jauco Noordzij