[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 #32 from Albert Astals Cid <tsdgeos at terra.es> ---
(In reply to comment #31)
> (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.

Trying fribidi is not the correct answer, we have already settled that ICU is
better. What I am asking if we should have that code as better than nothing
when the dependencies are not there. So in a world where i can't have ICU, does
having that code you removed gives better results than no code at all?

> > 
> > > 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. :-)

Ok, then i don't understand your complain/comment

> > 
> > > 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?

I still don't see why we really need this enum. If you create an enum, it means
you'll probably end up with someone exposing that as an option in the UI that
lets users choose this, and i don't see any of the programs i use asking me
which RTL handling method I want to use. Can't we just do *the right thing*?

Cheers,
  Albert

> 
> 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/20130218/831048ae/attachment.html>