[tei-council] [TEI-DIR-WG] Outcome of TEI Council discussion on Text Directionality

[Martin Holmes]

On 13-09-06 12:53 PM, Paul Schaffner wrote:
> Sounds reasonable. Do any of us have any actual experience
> with these? pfs

I've been playing with the transform functions that already work -- 
W3Schools has a sandbox:

<http://www.w3schools.com/cssref/css3_pr_transform.asp>

Cheers,
Martin

>
> On Fri, Sep 6, 2013, at 15:26, Kevin Hawkins wrote:
>> I hereby offer my general approval of the idea!  --Kevin
>>
>> On 9/6/2013 12:37 PM, Martin Holmes wrote:
>>> Hi everyone,
>>>
>>> This message is going both to the TEI Council and to the Text
>>> Directionality Working Group.
>>>
>>> Following the discussion below in April and my presentation at the TEI
>>> Council meeting, nothing has happened partly because I've been very
>>> busy, but partly because I've been waiting for changes in the CSS
>>> Writing Modes specification to settle down a bit, and for an answer to
>>> the question of why bottom-to-top writing modes are not included in CSS
>>> Writing Modes. I haven't had any luck with the latter so far, although
>>> I'm waiting for a message to the W3C Style mailing list on the topic to
>>> be approved.
>>>
>>> Meanwhile, I've been revisiting the proposal for new @rotate*
>>> attributes, and I wonder if there might be a better solution in CSS
>>> Transforms:
>>>
>>> <http://www.w3.org/TR/css3-transforms/>
>>>
>>> There are a number of reasons why I think this is a better approach:
>>>
>>> 1. It's an existing standard. Using an existing standard is always
>>> better than rolling your own, especially when we have already bought
>>> into CSS in the directionality part of the equation.
>>>
>>> 2. It's much richer than what we could achieve with our rotation
>>> attributes; in addition to simple 2D and 3D rotation, it allows (for
>>> instance) translation (moving an element relative to its base position),
>>> skewing, rotation around different origin points, and many other useful
>>> features.
>>>
>>> 3. It doesn't involve creation of any new attributes in TEI, so there's
>>> no need for argument about what elements should carry them.
>>>
>>> 4. User agents already have some support for 2D transforms and that
>>> support will increase over time. Where documents are being rendered in
>>> web browsers, it will be simpler for rendering pipelines to pass through
>>> CSS code where appropriate than to generate it based on TEI attributes.
>>> (This is a pragmatic point rather than a point of principle, of course.)
>>>
>>> If we do recommend an approach to layout description based on CSS
>>> Transforms rather than on new TEI attributes, we'll be presenting a
>>> unified approach to the two separate but related problems (true text
>>> directionality and rotational features).
>>>
>>> I'd be grateful to get feedback on this. If there's general approval for
>>> the idea, I'll update the workgroup Wiki page and the ticket:
>>>
>>> <http://wiki.tei-c.org/index.php/Text_Directionality_Workgroup>
>>> <https://sourceforge.net/p/tei/feature-requests/342/>
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 13-04-26 01:17 PM, Martin Holmes wrote:
>>>> Doh!
>>>>
>>>> SHOULD BE:
>>>>
>>>> The existing one is for rotate-z, so we could say that where there is a
>>>> single value, it applies to the z axis, and where there are multiple
>>>> values, they are x, y, z (two values would presumably not be allowed).
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 13-04-26 12:48 PM, Martin Holmes wrote:
>>>>> HI Marcus,
>>>>>
>>>>> I'm replying to this through the mailing list, so that it gets archived
>>>>> appropriately.
>>>>>
>>>>> I really like your idea of a single @rotate (rather than @rotation) with
>>>>> three values, especially because it holds out the promise of
>>>>> backward-compatibility with the existing @rotate attribute. The existing
>>>>> one is for rotate-x, so we could say that where there is a single value,
>>>>> it applies to the x axis, and where there are multiple values, they are
>>>>> x, y, z (two values would presumably not be allowed). This would be even
>>>>> more perfect if the current @rotate were x (the first of the three), but
>>>>> I guess we can't have everything.
>>>>>
>>>>> On the other hand, if we create a new @rotation attribute, we can do
>>>>> what we like with it, and perhaps deprecate the old @rotate after a
>>>>> specified length of time.
>>>>>
>>>>> Regarding bottom-to-top, I appreciate the simplicity of going with pure
>>>>> CSS for the moment, but I would like to find out why it's not in there,
>>>>> and if there are plans to add it. If there's a principled objection to
>>>>> it, we might well want to suggest alternatives.
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>>
>>>>> On 13-04-26 11:51 AM, Marcus Bingenheimer wrote:
>>>>>> Dear Martin,
>>>>>>
>>>>>> Thanks for that clear presentation and summary. I think we can be
>>>>>> satisfied
>>>>>> with the outcome.
>>>>>>
>>>>>> 1. As for the bottom-to-top issue I want to argue the following:
>>>>>> CSS is likely to include bottom-to-top writing at one point, if not for
>>>>>> Batak, Hanuno'o and Ancient Berber, then for the sheer ornamental
>>>>>> purposes.
>>>>>> This might come in tandem with a solution for writing along paths /
>>>>>> Bézier curves.
>>>>>> Instead of adding complexity to our recommendation we might be better
>>>>>> off
>>>>>> admitting incompleteness. In case someone is working on one of the
>>>>>> extremely rare bottom-top scripts in TEI, the writing direction and its
>>>>>> implementation is going to be a major issue in any case and has to be
>>>>>> addressed specifically, probably somewhere in the header. I suggest
>>>>>> we do
>>>>>> not offer additional functionality for bottom-top, which might become
>>>>>> obsolete as CSS evolves, but rather say @style should follow CSS to its
>>>>>> present capabilities and recommend to record information on writing
>>>>>> systems
>>>>>> and direction that goes beyond that in the header for now.
>>>>>>
>>>>>>
>>>>>> 2. Regarding the scoping of the @rotation-x-y-z:
>>>>>> I am for the most "liberal" scoping as I want to rotate not only inline
>>>>>> text but also images.
>>>>>> By the way, have we considered to have only one @rotation which takes
>>>>>> three
>>>>>> values (x, y, z)? Something like @rotation="0 180 0" (180 along
>>>>>> y), @rotation="50 0 90" (50 along x and 90 along z)
>>>>>>
>>>>>> all the best
>>>>>>
>>>>>> marcus
>>>>>>
>>>>>> On Thu, Apr 25, 2013 at 12:26 PM, Martin Holmes<mholmes at uvic.ca>  wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> This is a joint message to the TEI Council list and to the Text
>>>>>>> Directionality Working Group list.
>>>>>>>
>>>>>>> We had a TEI Council meeting in Providence a couple of weeks ago, and I
>>>>>>> made a presentation on the work we've done so far on text
>>>>>>> directionality.
>>>>>>> The slides of the presentation are here:
>>>>>>>
>>>>>>> <http://wiki.tei-c.org/images/**4/48/Text_directionality.pdf<http://wiki.tei-c.org/images/4/48/Text_directionality.pdf>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> and the minutes from the Council meeting are here:
>>>>>>>
>>>>>>> <http://www.tei-c.org/**Activities/Council/Meetings/**
>>>>>>> tcm54.xml#body.1_div.1_div.3_**div.1<http://www.tei-c.org/Activities/Council/Meetings/tcm54.xml#body.1_div.1_div.3_div.1>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> At the meeting, I made the following three proposals:
>>>>>>>
>>>>>>> 1. That we ignore Unicode for the moment, mainly because it's not
>>>>>>> relevant
>>>>>>> for us (UTR #20 Unicode in XML and other Markup Languages
>>>>>>> advises that bidi embedding (and presumably isolate) control characters
>>>>>>> NOT be used in XML markup), and because it's moving VERY slowly on
>>>>>>> vertical
>>>>>>> orientation anyway (recent UTR #50 revisions have considerably
>>>>>>> reduced its
>>>>>>> scope in this regard).
>>>>>>>
>>>>>>> 2. That we formally adopt CSS Writing Modes, and provide examples of
>>>>>>> how
>>>>>>> to use it through the @style attribute.
>>>>>>>
>>>>>>> 3. That we create @rotate-x, @rotate-y and @rotate-z attributes to
>>>>>>> capture
>>>>>>> all manner of rotation (which can also help to handle edge-cases of
>>>>>>> directionality such as boustrophedon).
>>>>>>>
>>>>>>> There was a generally favourable reaction to all three proposals, and I
>>>>>>> was tasked with summarizing them to the Council list and to the working
>>>>>>> group, which I'm now doing.
>>>>>>>
>>>>>>> These were some issues that Council would like to see addressed:
>>>>>>>
>>>>>>> 1. CSS WRITING MODES AND BOTTOM-TO-TOP SCRIPTS:
>>>>>>>
>>>>>>> It's notable that the CSS Writing Modes draft explicitly excludes
>>>>>>> bottom-to-top vertical text: "Inherently bottom-to-top scripts are not
>>>>>>> handled in this version. See [UTN22] for an explanation of relevant
>>>>>>> issues." I personally don't see anything in UTN22 that justifies this
>>>>>>> exclusion, and indeed very recent changes to CSS Writing Modes seem
>>>>>>> to be
>>>>>>> designed to fudge some accommodation for bottom-to-top into the system:
>>>>>>> "The ‘sideways-left’, ‘sideways-right’, and ‘sideways’ values of
>>>>>>> ‘text-orientation’ are provided for decorative layout effects and to
>>>>>>> work
>>>>>>> around limitations in CSS support for bottom-to-top scripts."
>>>>>>>
>>>>>>> Council asked me to contact the W3C working group and clarify the
>>>>>>> exclusion of bottom-to-top scripts. Before I do that, I've been
>>>>>>> trying to
>>>>>>> figure out if there's any existing discussion of it on their public
>>>>>>> discussion list:
>>>>>>> <http://lists.w3.org/Archives/**Public/www-style/<http://lists.w3.org/Archives/Public/www-style/>>.
>>>>>>>
>>>>>>>
>>>>>>> I'd appreciate any help with this that you have time to give.
>>>>>>>
>>>>>>> If the specification is leaving out bottom-to-top because of the
>>>>>>> lack of
>>>>>>> sufficient scripts in Unicode that are oriented that way, then maybe
>>>>>>> Debbie
>>>>>>> can let us know whether there are more bottom-to-top scripts on the
>>>>>>> road
>>>>>>> for inclusion in Unicode; we might be able to use that as an argument
>>>>>>> for
>>>>>>> more robust support for it in CSS Writing Modes.
>>>>>>>
>>>>>>> 2. PROPOSAL #3: WHAT ELEMENTS SHOULD HAVE THESE NEW ATTRIBUTES
>>>>>>>
>>>>>>> Currently, the TEI @rotate attribute (which really means rotate-z,
>>>>>>> rotation around the z axis) is available only on<zone>. The three
>>>>>>> attributes we propose, one of which would replace it, would be
>>>>>>> provided as
>>>>>>> a class. The question is what elements should be members of that class.
>>>>>>>
>>>>>>>     - The most conservative approach would be to keep it only to
>>>>>>> <zone>, so
>>>>>>> you could only use rotation if you're using the Facsimile module.
>>>>>>>
>>>>>>>     - Another would be to say that rotational features are inherently
>>>>>>> topographical, and therefore all suitable elements in the genetic
>>>>>>> editing
>>>>>>> set (<line>  etc.) might also bear them.
>>>>>>>
>>>>>>>     - Most liberally, we might say that these rotational attributes
>>>>>>> may be
>>>>>>> essential in any kind of transcription, so they should be available
>>>>>>> on any
>>>>>>> transcription-bearing element in<text>  or<sourceDoc>.
>>>>>>>
>>>>>>> I'd be grateful for your feedback on this, and any insights anyone can
>>>>>>> glean from the W3C style list archives regarding bottom-to-top text.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Martin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Martin Holmes
>>>>>>> University of Victoria Humanities Computing and Media Centre
>>>>>>> (mholmes at uvic.ca)
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> --
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)