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

Subject: Re: [jats-list] encoding width or height of inline-graphic
From: "Imsieke, Gerrit, le-tex gerrit.imsieke@xxxxxxxxx" <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 24 Apr 2020 07:44:35 -0000
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_Information_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