[tei-council] [TEI-DIR-WG] Outcome of TEI Council discussion on Text Directionality
Martin Holmes
mholmes at uvic.ca
Fri Sep 6 13:46:05 EDT 2013
Hi Marcus,
On 13-09-06 10:00 AM, Marcus Bingenheimer wrote:
> Hallo Martin,
>
> I second your suggestion. All the four points you raise are relevant, to
> my mind especially 1 and 3.
> Since CSS, like TEI, keeps evolving it might be good to suggest that the
> version one uses must noted somewhere in the teiHeader. Perhaps as part
> of @scheme on <rendition>, but by default that is limited too the value
> 'css'.
> I would prefer a more prominent place and the ability to specify CSS 2.x
> etc.
I'm copying this to Council because it's a broader point that we'll have
to address outside of the directionality/rotation issue.
CSS from version 3 onwards is modular, and modules are versioned
independently. There are already some level 4 modules, for instance. I
don't think it's going to be possible for anyone to say in a single
location in a document that they're using CSS version X; most of the CSS
we currently use was defined in versions 1 through 2.1, and now we'll be
suggesting the use of properties from two level 3 modules, but we may
also recommend level 4 modules in future. I think it would make sense
for a particular section in the Guidelines to point to a specific CSS
specification -- we propose to recommend CSS Writing Modes 3 in our
upcoming addition on text directionality, and all our examples would
reflect that, but a future version of the Guidelines might be revised to
point to a level 4 Writing Modes module if that were more appropriate
(for instance if they added support for bottom-to-top directionality).
So I think we're going to need a place to document the precise CSS
modules that people are drawing from in their use of @style. The
question really is whether this is going to need to be machine-readable,
or whether a prose explanation would be sufficient. If the latter, then
somewhere in <encodingDesc> is fine. Personally, I'm not sure that
there's a need for a machine-readable method, because I don't know what
machine would ever be trying to parse the CSS in a TEI file. The raw CSS
itself is human-readable and comprehensible (albeit with help from the
specifications), so it's ideal as a descriptive tool. Generally, if the
CSS is copied or transformed into output during a rendering process,
then a browser will be the target user agent, and browsers as far as I
can see simply play continual catchup with the existing standards, and
don't advertise themselves as "CSS3 compliant"; they render what they
can render and ignore the rest.
One possible imaginable scenario might be the need to convert from TEI
to XSL:FO. FO uses many properties from CSS2, but it often modifies or
enhances them. It might be possible to write conversions between
(modules at) various CSS levels into the equivalent attribute-sets in
XSL:FO, and therefore it might be useful to be able to machine-read the
relevant CSS levels from the TEI file, but this seems a rather unlikely
situation.
Cheers,
Martin
>
> all the best
>
> marcus
>
>
>
>
>
> On Fri, Sep 6, 2013 at 12:37 PM, Martin Holmes <mholmes at uvic.ca
> <mailto:mholmes at uvic.ca>> 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/
> <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
> <http://wiki.tei-c.org/index.php/Text_Directionality_Workgroup>>
> <https://sourceforge.net/p/__tei/feature-requests/342/
> <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 <mailto: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>__<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/**
> <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
> <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/><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 <mailto:mholmes at uvic.ca>)
>
>
>
>
>
>
>
> --
> Martin Holmes
> University of Victoria Humanities Computing and Media Centre
> (mholmes at uvic.ca <mailto:mholmes at uvic.ca>)
>
>
>
>
> --
> Dr. Marcus Bingenheimer 馬德偉
> Department of Religion, Temple University
> http://mbingenheimer.net
--
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)
More information about the tei-council
mailing list