[Framers] LTR in RTL issue...

[Scott Prentice]

For a single-use XSLT, I'd just set it up to be run as one of the steps 
in the workflow rather than make it part of a structured app.

I may end up adding this functionality into DITA-FMx, and might also 
release it as a stand-alone tool (if anyone is interested). But will 
wait and see how (or if) the client wants to incorporate this into their 
workflow. I'll let you know!

Cheers,
...scott



On 9/25/16 6:38 AM, Heiko Haida wrote:
>
> Well, normally the layout work is a one-way thing.
>
> Of course you could try to add another XSLT for converting the marks 
> back to attributes while checking in the data.
>
> I would be interested to know what kind of solution/workflow you are 
> going to establish, maybe you can share this on occasion.
>
> Good luck -- Tino
>
>  Scott Prentice:
>
>> Hi Tino...
>>
>> I'm thinking that the problem with using XSL in the structured app is 
>> that it would continue to add the marks every time the file is 
>> opened. It seems like you'd want to have some logic that could add 
>> the marks as needed, if they don't already exist.
>>
>> I need to discuss the possible workflow with my client, and see what 
>> would work best. Now that I see how it works, we should be able to 
>> work something out.
>>
>> Thanks!
>> ...scott
>>
>>
>> On 9/24/16 3:52 PM, Heiko Haida wrote:
>>>
>>> Hi Scott,
>>>
>>> I would use an XSL-transformation as part of the structured 
>>> application for these elements with "dir"-attribute. This could add 
>>> the marks as real characters in the text.
>>> Maybe prefix and suffix are solitary containers in FrameMaker that 
>>> are not thought to influence any more portions of the *real* text 
>>> (only a guess).
>>>
>>> I use an Extend script that sets the markers for a selected text 
>>> analogously to Indesign (this makes it a little bit easier for the 
>>> layout work in the good old-fashioned way).
>>>
>>> ...Tino
>>>
>>> Scott Prentice:
>>>
>>>     Thank you Tino!
>>>
>>>     This does seem to work (mostly)! Yes .. you'd think that the
>>>     translator should be doing this, as it would be part of a proper
>>>     translation. I'm working with XML markup and I'm thinking that
>>>     you might be able to add these "marks" as prefix and suffix
>>>     rules to certain elements, controlled by the @dir attribute. If
>>>     @dir='ltr' set the prefix to LTR override and the suffix to POP.
>>>
>>>     ... testing ...
>>>
>>>     Hmm .. bummer. It doesn't seem to work. It looks like the EDD
>>>     isn't applying the marks for prefix and suffix. If I manually
>>>     add the marks before and after the .. <ph dir='ltr'>Fn + %</ph>
>>>     .. it works right (and displays like "Fn + %"). But with the
>>>     EDD-applied marks, it stays like this .. "% + Fn". Seems like a
>>>     FM bug?
>>>
>>>     I suppose I could create a plugin to add these marks to elements
>>>     with the @dir attribute, but then I'd need to be sure to strip
>>>     them off on file save, else they'd keep getting added .. hmm.
>>>
>>>     Anyway .. thanks for your help!
>>>
>>>     Cheers!
>>>     ...ttocs
>>>
>>>
>>>
>>>     On 9/24/16 5:06 AM, Heiko Haida wrote:
>>>
>>>         Hi Scott,
>>>
>>>         when it comes to a mixture of LTR in a RTL context, the
>>>         software will also recognize the "natural" direction of
>>>         every character.
>>>
>>>         For now, you can only change this in FrameMaker by adding
>>>         "bidirectional marks". There a is an extra palette for this.
>>>         This is not a character format you could apply to a text
>>>         range, like in Indesign. I already suggested a more
>>>         intuitive solution for this in FrameMaker (in Indesign ME,
>>>         it is pretty easy to control).
>>>
>>>         How do these marks works? --> Well, I am always trying until
>>>         it fits: You add a start mark and an end mark, eg. LRO/PDF
>>>         or LRI/PDI, or LRO combined with RLO to switch back.
>>>         Sometimes, the closing mark is not necessary. Of course,
>>>         there is an exact definition in Unicode about how the
>>>         different marks should work.
>>>
>>>         In a perfect translation, the translator should already have
>>>         added the marks. (Well, this is just a dream... -- never
>>>         heard of any translator who would know this).
>>>
>>>         pls also see: https://en.wikipedia.org/wiki/Bi-directional_text
>>>         Or look it up in the Unicode manuals.
>>>
>>>         Best regards -- Tino H. Haida, Berlin
>>>
>>>         Scott Prentice:
>>>
>>>             Hi...
>>>
>>>             In FM 2015 .. is there a "text range" property to change
>>>             the text direction? I'm only seeing this in the
>>>             paragraph properties, but not in character properties.
>>>
>>>             I know that it's supposed to "properly" flip English
>>>             text, but it appears that there are cases where this
>>>             doesn't work quite right. (I'm no expert on this
>>>             formatting, so I can't really say what's "right", but
>>>             it's apparently not what's wanted.)
>>>
>>>             For example, if you have an Arabic paragraph formatted
>>>             as LTR, and in that paragraph you have some English
>>>             words that terminate with a special character of some
>>>             kind or even an inline image. In this case, the English
>>>             words will properly flip to RTL, but the special
>>>             character or image (at the end of the English words)
>>>             will be on the left of those words, when you want it to
>>>             be on the right. Adding more English words (or a
>>>             character) "after" the image or special character will
>>>             make it flip back to the right of the English words ..
>>>             but if you want this character or image to be at the end
>>>             (on the right) of the English phrase, you're out of luck
>>>             it seems.
>>>
>>>             If there was a text range property that could be applied
>>>             to the characters that you always want to be RTL in the
>>>             middle of an LTR para, this would work just fine. (I think.)
>>>
>>>             Anyway .. I don't think that what I'm looking for exists
>>>             in FM, but I'm asking on the off chance that it might.
>>>
>>>             Thanks!
>>>             ...scott
>>>
>>>