Alan Yaniger wrote:
Hi Philipp,
Thanks, I guess I wasn't clear enough. I had already begun reversing the
sort order in pdfiprocessor.cxx. This got the text order to appear
properly, but not the spacing, and not the margins. So I wasn't
finished. But if I understand properly, this is an unnecessarily
complicated way to go about things. Since when loading the file, Draw
calls the bidi layout code, changing the sort order in the PDF import
would mean to reverse the text, only to have it un-reversed in Draw.
Wouldn't it be simpler if the text was never reversed at all? Also, as
you point out, mixed-direction text is not solved, so all text which
consists of numbers would come out backwards. If the text is imported
visually, this will not be a problem. The text would be imported as is,
without calling the bidi layout code, and each glyph would be in its
proper place.
Certainly one could skip the sorting wholesale (which would give the
"visual" order you mean). The problem is that (regardless of RTL-LTR
problems) text can be set to the same geometrical arrangement on so many
ways. I'll try to picture an extreme case
A5 B2 C6
D4 E1 F3
Consider each combination a text portion (a single glyph, perhaps a
word, whatever). To achieve the ordering given by the letters you could
output the portions in the order of the numerals. An while the first
particular order may seem a bit weird, it could very well be the case
that text is output in this way, depending on the font attributes
involved (or just to put more pain on people wanting to import PDF I
presume ;-) ). The sorting is supposed to bring the PDF import into atr
least some kind of order, namely the same situation an Optical Character
Recognition (OCR) software would be in.
Of course it would make sense not to do this and hope that the PDF
creating software put out text in a more useful manner. Personally I
think we need to have this user configurable, so the user can try which
kind of ordering (including none at all) gives the best result. This is
definitely a filter that needs help from the user to figure out what
would be sensible strategy reading the document.
So what I'm looking for is a way to create the Draw text object so that
Draw will import RTL text exactly as it imports LTR text - a way for it
to not call the bidi algorithm, even for text in an RTL language. Maybe
this means the change should (also) be in Draw, and not (just) in PDF
import?
I frankly don't know. On this probably Christian, Thorsten and Andre can
say more ?
Kind regards, pl
--
Someone told me: "Smile and be happy, it could be worse"
And I smiled and was happy and things became worse.
-- Author unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
