#467 stylesheets do not handle multiple values in @target

AMBER
closed
1(low)
2013-11-04
2012-11-05
No

== Summary ==

The stylesheets do not handle multiple values in @target.

== Versions ==

Ubuntu 12.10

$ dpkg-query -W tei-p5-xsl2
tei-p5-xsl2 6.18

== How to Reproduce ==

1. Download the attached zip file.

2. Unzip. Cd into directory.

3. Execute:

$ make

This will produce a test.html file and a test.ltx file.

== Expected Results ==

The test.xml file contains <ptr target="#P1 #P2"/>. The test.html file should have a corresponding structure to link to P1 and P2. It should probably be a pair of <a href=...>...</a> elements.

Similarly, the test.ltx file should contain a corresponding structure to link to P1 and P2. It should probably be a pair of \hyperlink commands.

== Actual Results ==

<ptr target="#P1 #P2"/> is converted in test.html as:

<a href="#P1" class="link_ptr" itemprop="ptr">here</a>

... and in test.ltx as the rather humorous:

\hyperlink{P1 #P2}{here}

== Observations ==

The P5 documentation gives at least one example of multiple target values and also explicitly mentions the possibility of multiple values in the explanation of @target. (This is the example given with the <ptr> element: <ptr target="#p143 #p144"/>.)

The test.ltx file also lacks appropriate \hypertarget commands to mark where \hyperlink commands should point to, hence none of the links work.

Upon cursory inspection of the stylesheets, I believe the problem is present in the common2 files, and thus common to most, if not all, conversions.

I've tried teitoodt, just to see, and find the problem is present there too. The problematic link has a target of "P1 #P2".

Discussion

  • files illustrating the bug

     
    Attachments
  • you're entirely right, as usual, Of course, its not clear what to do. I am just concatenating two hyperlinks with no separator. What does it _mean_ to have two targets on a <ptr>?

    Fixed for HTML and LaTeX, need to look at odt and docx.

     
    • status: open --> open-accepted
     
  • James Cummings
    James Cummings
    2012-11-06

    If there are two values of @target on <ptr/> surely it means it is pointing to two places... how to represent this in output varies depending on the output. For our current outputs I'd suggest just putting the equivalent of two pointers separated by a space. So for <ptr target="#section12 http://www.example.com/foo.xml#section13"/> I would expect something like:

    <a href="#section12">Section 12</a> <a href="http://www.example.com/foo.xml#section13">Foo Section 13</a>

    in html. Depending on what it is pointing to of course.

    -James

     
  • A default algorithm that represents in the output all the values of @target and produces meaningful output would make sense. So putting white space to separate the linking elements produced for the multiple values of @target makes sense.

    At the same time, it very rarely the case that in actual usage pointers separated by spaces would work for me. I'd almost always want something else. Most often, I think I'd want <ptr target="#P1 #P2 ... #Pn"> to be equivalent to:

    <ptr target="#P1">, <ptr target="#P2">, <ptr target="#P3">, ..., <ptr target="#Pn-1"> and <ptr target="#Pn">

    Of course this is language-dependent. However, if the stylesheets default to separating the elements by white spaces, then I'd *always* have to customize how links are produced to get what I want.

    There are perhaps very good reasons trying to implement what I'd like would require changes to the stylesheets that are too ambitious at this stage of the evolution of TEI, or is undesirable for another reason. If so, then I would still like the solution to provide for a least intrusive way to override the default behavior. Maybe a template, designed with the intent of it being readily overridable, which would produce a separator upon being called with the index number of the @target value that will be output next and the total number of values would allow for a "least intrusive way" to do what I'd like?

     
  • I have pretty much implemented this, and it seems to work so far. I need to merge the code in with teitodocx transform though.

    See <xsl:template name="multiTargetSeparator"> for the default code

     
  • Sebastian, I've taken a look at the template. Thank you for implementing it that way.

    However, I believe that it will fail (baring some i18n magic I'm unaware of) for zh-TW, since Chinese simply uses the enumeration comma (U+3001 IDEOGRAPHIC COMMA) between all elements of an enumeration:

    X1、 X2、 ...、 Xn-1、 Xn.

    If there is an i18n group, it might be worth putting the problem to them before moving forward, to avoid surprises.

     
  • Chinese separator is in place

     
  • docx support now in place, so closing this ticket

     
    • status: open-accepted --> closed
    • Group: --> AMBER
    • Priority: 5 --> 1(low)