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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [jats-list] encoding width or h, Imsieke, Gerrit, le- | Thread | [jats-list] JATS-Con 2020 was to be, Beck, Jeff (NIH/NLM/ |
Re: [jats-list] encoding width or h, Imsieke, Gerrit, le- | Date | [jats-list] JATS-Con 2020 was to be, Beck, Jeff (NIH/NLM/ |
Month |