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

Hmmm, not sure i understand what you mean here, what is "the code before lastly
patched"?

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

What do you mean by "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.

With could do you mean "I know there is a PDF hint for that" or you mean "maybe
there is a PDF hint for that"?

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

Probably TextOutputDev makes more sense, I have not much experience in RTL (as
it shows ;-)) but i don't think it would make sense to have a TextPage of a
document using one method and the next TextPage of the same document using a
different method, no?

> > 
> > 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/20130303/ca375f0e/attachment.html>