[Framers] LTR in RTL issue...

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