[Poppler-bugs] [Bug 55977] handling of rtl text inversion is too naive

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=55977

--- Comment #31 from alex <alexbodn.groups at gmail.com> ---
(In reply to comment #30)
> (In reply to comment #29)
> You are removing lots of code, e.g. the "// Note: This code treats numeric
> characters (European and", why? Can't we use that when ICU is not there?

it's not working properly, at all. rather try fribidi.
> 
> > cmake related stuff is there, but i have no idea on how to use it. my env is
> > debian linux with gnome.
> 
> And what's the problem? cmake works perfectly in debian linux with gnome :-)
debian is building using gnu make and friends, hence i've never encountered
cmake before. no other problem on my part. :-)
> 
> > as for finding (a) better place(s) to store reordering_mode, i'd like to
> > consult you.
> 
> Sure, what's the question?
> 
the reordering mode helps taking us back to the logical (typing order) text
that would be visualized in the order shown by the doc. 
on windows systems, ReorderingNumbersSpecial would normally prevail, while on
pure unicode systems: ReorderingLikeDirect.
this assumption should guide the text conversion, according to the client that
is requesting it: either by the very system, in case of a stand alone or local
process application, or by the remote client's mode in case of a server
performing the conversion.

in our case, i'd define a reordering_mode at the TextOutputDev object level,
with the local system as default, that would be overrideable in the getText and
findText methods calls, especially when called from different systems.
should the reordering mode be selectable in pdftotext too?

should i then move the reordering mode enum to the TextOutputDev object?

what would you think?
alex

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/poppler-bugs/attachments/20130214/893e209f/attachment.html>