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

[Paul Schaffner]

Sounds reasonable. Do any of us have any actual experience
with these? pfs

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
-- 
Paul Schaffner  Digital Library Production Service
PFSchaffner at umich.edu | http://www.umich.edu/~pfs/