[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 #33 from alex <alexbodn.groups at gmail.com> ---
(In reply to comment #32)
> (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?
sorry, it's not better than nothing. btw, the code before lastly patched could
be treated as "better than nothing", but not this one.
> 
> > > 
> > > > 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
no complaint on my part, just an excuse for not adding icu in the cmake build
system on account of my ignorance.
> 
> > > 
> > > > 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*?
the right thing should be default, based on the os of the system the dumped
text is requested on.
as i said, this will be determined at compilation time for stand alone, but
determined at run time on systems serving clients on various platforms.
yet, maybe the os checking could be not enough, and the document could contain
additional hints for choosing this default.

what i was asking you is your opinion on moving this enum higher in the objects
hierarchy, in order to further use it as an optional parameter when creating
the TextOutputDev object.
> 
> Cheers,
>   Albert
> 
thanks,
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/20130224/848c1449/attachment.html>