Re: [jats-list] encoding width or height of inline-graphic

Subject: Re: [jats-list] encoding width or height of inline-graphic
From: "Gareth Oakes goakes@xxxxxxx" <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 24 Apr 2020 08:03:56 -0000
Sorry to wade in here but I think the problem with all of this is not
necessarily the distinction between style and semantics but the fact that the
handling of images is very much dependant on the output device. Print, laptop
screen, mobile screen, screen reader for the visually impaired, you get the
idea.

Storing a value of x="600px" y="500px" might help the laptop screen but not
the mobile screen. What does a px even mean on a printed page? Do you assume
96ppi? 72ppi? Perhaps the image files have the intrinsic dimensions in EXIF or
other metadata that you can use, but then what about the image files that
don't?

My personal opinion is that image handling is best deferred to the output
device e.g. the pagination software or web browser. On the other hand though,
I am quite pragmatic by nature and agree that being able to store image
dimensions for reasons of practicality shouldn't be excluded on "religious"
grounds __

I'm not sure if that helps or not but perhaps gives another angle for
consideration.

// Gareth Oakes
// Chief Architect, GPSL
// www.gpsl.co

o;?On 24/4/20, 17:44, "Imsieke, Gerrit, le-tex gerrit.imsieke@xxxxxxxxx"
<jats-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

    Hi Pieter,

    Separating style and content is considered a good idea, but imagine that
    you didnbt have an <italic> element in JATS and people would tell you to
    use <styled-content id="phrase384">highlighted text</styled-content> in
    the document and provide
    #phrase384 { font-style: italic }
    in a separate CSS document.

    This is simply to illustrate that JATS isnbt too dogmatic about the
    separation of structure and styling. There are actual elements for
    communicating common styling information. People may argue that image
    dimensions are also common styling information.

    Regarding including actual page numbers in JATS:

    You can specify at least <fpage> and <lpage> for an article in the
    metadata.

    In addition, there is currently a request for the BITS working group to
    add <page-start> and <page-end> with actual page numbers in the content.
    This request hasnbt been dealt with so far.

    The problem with putting image dimensions into CSS during conversion
    pipelines is that you need to associate the CSS file with the content
    file. As sketched above, there is no way to put things like

    #img-4.2 {width:74mm; height:39mm}

    into JATS/BITS/STS frontmatter.

    In addition, any information that is serialized as CSS needs to be
    parsed by subsequent conversion steps (unless the CSS may be included
    literally, but sometimes the target of a JATS/BITS/STS conversion is not
    HTML/CSS, but another XML vocabulary).

    Putting an ad-hoc syntax for width and height into @specific-use also
    increases the amount of parsing that is necessary, and the amount of
    documentation needed.

    An approach that we often pursue is to extend a base vocabulary
    (DocBook, TEI, BITS [1]) with attributes in the css namespace [2,3]. If
    you donbt want this layout information, you can easily strip away
    everything in the css namespace. But such an extended schema is not an
    option for our customersb STS workflow that motivated my question to
    this list.

    Gerrit

    [1] https://hobots.hogrefe.com/schema/hobots.rng
    [2]
    https://archive.xmlprague.cz/2013/presentations/Conveying_Layout_Informat
ion_with_CSSa/CSSa_xmlprague_gimsieke.html
    [3] https://github.com/le-tex/CSSa


    On 24.04.2020 08:55, Pieter Lamers pieter.lamers@xxxxxxxxxxxx wrote:
    > Hi Gerrit,
    >
    > I believe we do that in the CSS. JATS tries to stay away from real life
    > things like page numbers, so why would it need fixed size? I think we
    > also occasionally see the need to record an original size, if only for
    > knowing the aspect ratio. There is always SQL then, where we would
    > record additional info.
    >
    > Best,
    > Pieter
    >
    > On 20/04/2020 21:17, Imsieke, Gerrit, le-tex gerrit.imsieke@xxxxxxxxx
    > wrote:
    >> Hi JATS/BITS/STS people,
    >>
    >> How do you encode widths or heights of <graphic> and <inline-graphic>
    >> onjects?
    >>
    >> I'm primarily interested in conveying the desired widths or heights to
    >> a renderer, in units such as em, mm, %, or px, or as unitless decimal
    >> numbers.
    >>
    >> The <inline-graphic> objects aren't characters, so I can't use
    >> private-char/glyph-data/@x-size etc.
    >>
    >> Or asked this way: Does anyone know why @x-size and @y-size aren't
    >> allowed on graphic and inline-graphic? Width and height attributes on
    >> images and other media objects are common in other vocabularies.
    >>
    >> -- Gerrit
    >>
    >

    --
    Gerrit Imsieke
    GeschC$ftsfC<hrer / Managing Director
    le-tex publishing services GmbH
    Weissenfelser Str. 84, 04229 Leipzig, Germany
    Phone +49 341 355356 110, Fax +49 341 355356 510
    gerrit.imsieke@xxxxxxxxx, http://www.le-tex.de

    Registergericht / Commercial Register: Amtsgericht Leipzig
    Registernummer / Registration Number: HRB 24930

    GeschC$ftsfC<hrer / Managing Directors:
    Gerrit Imsieke, Svea Jelonek, Thomas Schmidt

Current Thread