Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support multiple image resolutions #49

Open
ndw opened this issue Sep 24, 2015 · 14 comments
Open

Support multiple image resolutions #49

ndw opened this issue Sep 24, 2015 · 14 comments
Assignees
Labels

Comments

@ndw
Copy link
Contributor

@ndw ndw commented Sep 24, 2015

From SourceForge RFE 308 by Philipp Bachmann:

In the age of concurrently having devices with vastly different resolutions a document should provide image resources in several resolutions in parallel. Regarding DocBook and DocBook XSL this has been discussed on the "docbook"-mailing list in the second half of 2013 (thread "Simplifying image markup"), but to my knowledge never made it into an RFE. So I do that now.
Regarding DocBook XSL with HTML output in 2013 Jirka provided two referencds possibly to consider:
http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/ (now part of the HTML specification) and
http://picture.responsiveimages.org/
Facing the dissemination of High Resolution displays this topic is of increasing importance in my opinion.

@ndw

This comment has been minimized.

Copy link
Contributor Author

@ndw ndw commented Sep 24, 2015

I believe that this case is already covered by mediaobject:

<article xmlns="http://docbook.org/ns/docbook">
<title>Example mediaobject</title>

<mediaobject>
  <info>
    <othercredit>
      <orgname>O'Reilly Media</orgname>
    </othercredit>
    <othercredit>
      <orgname>Dover Archives</orgname>
    </othercredit>
  </info>
  <alt>The DocBook: TDG Duck</alt>
  <imageobject>
    <imagedata align="right" width="6in" format="PNG"
           fileref="figs/web/duck-6in.png"/>
  </imageobject>
  <imageobject>
    <imagedata align="right" width="6in" format="GIF"
           fileref="figs/web/duck-6in.gif"/>
  </imageobject>
  <imageobject>
    <imagedata align="right" width="2.5in" format="PNG"
           fileref="figs/web/duck-25in.png"/>
  </imageobject>
  <imageobject>
    <imagedata align="right" width="1in" format="PNG"
           fileref="figs/web/duck-1in.png"/>
  </imageobject>
  <textobject>
    <para>The bird on the cover of <citetitle>DocBook: The Definitive
Guide</citetitle> is a wood duck.  Often considered one of the most
beautiful ducks in North America, the male wood duck has a metallic
purple and green head with white streaks extending from its bill
around the eyes and down to its blue and green, gold-flecked
wings. It has a white neck, chestnut-colored chest, a white or red
bill, and yellow-orange legs and feet. Females have more brown, gray,
and subdueed hues.</para>

  </textobject>
</mediaobject>
</article>

How is that insufficient?

@bachlipp

This comment has been minimized.

Copy link

@bachlipp bachlipp commented Oct 7, 2015

Hi Norman,

as I understand the DocBook manual, the alternative imageobjects in a single mediaobject are being chosen from by the so-called processing system. In my understanding a device like a web browser is not a processing system, but the combination of the DocBook XSL stylesheets and an XSL processor is - so, HTML output given, the resulting tag will be something like an img element with an src attribute, and that's what the DocBook XSL stylesheets basically actually do.

What I am missing is a means to specify alternatives that are not being decided on by the processing system. In case of HTML they would result e.g. in an img element and the more recent srcset attribute. I skimmed through the respective file of the DocBook XSL stylesheets and did not find anything generating "srcset" there, what further contributed to my belief that this is currently not possible with DocBook itself.

Cheers,
Philipp

@ndw

This comment has been minimized.

Copy link
Contributor Author

@ndw ndw commented Oct 7, 2015

I think the stylesheets should be updated to produce a srcset from a set of mediaobjects. The fact that the browser is now capable of making the choice "at runtime" is a new feature that we should be taking advantage of.

It's possible, however, that some new markup will have to be introduced. The question is, should all the alternatives always be used to make a srcset or only some of them?

I wonder if the following rules would work:

  1. The stylesheets choose an initial image using the currnet rules.
  2. All subsequent images that have the same format are grouped into a srcset.

That provides the option of having both .eps or .pdf images in a mediaobject for print and a set of gif or png or jpg images for online.

@ndw

This comment has been minimized.

Copy link
Contributor Author

@ndw ndw commented Nov 18, 2015

In fact, closer inspection reveals that we planned for this by allowing multiple imagedata elements inside imageobject, specifically so that a browser could select the right one. I think that the stylesheets should generate a srcset from multiple imagedata elements in the selected mediaobject.

@kosek kosek added schema v52 labels Jun 22, 2016
@kosek kosek removed the v52 label Jan 18, 2017
@kosek kosek self-assigned this Jan 18, 2017
@kosek

This comment has been minimized.

Copy link
Contributor

@kosek kosek commented Apr 11, 2017

It seems that the most viable solution is to add few additional attributes to imagedate element. However we can't directly use model used in <picture> and <source> elements in HTML5 as DocBook @fileref attribute expects just URL of one images whereas @srcset HTML attribute can reference multiple images. We can solve this by using some repetition in DocBook markup.

I propose to add the following 4 new attributes to <imagedata> element:

  • media -- same as media attribute on <source> element in HTML5
  • sizes -- same as sizes attribute on <source> element in HTML5
  • widthdescriptor -- number describing width which should be put into scrset attribute
  • pixeldensity -- number describing pixel density of image

widthdescriptor and pixeldensity are exclusive attributes.

When generating HTML5 output imagedata will be grouped based on values in media and sizes attributes and also based on presence of widthdescriptor and pixeldensity attributes. Then for each such group new <source> element will be produced with media and sizes attributes. srcset attribute will be generated based on values in fileref, widthdescriptor and pixeldensity values.

Image without any new attributes will be treated as a fallback (<img> element).

For example:

<picture>
  <source media="(min-width: 40em)"
    srcset="big.jpg 1x, big-hd.jpg 2x">
  <source 
    srcset="small.jpg 1x, small-hd.jpg 2x">
  <img src="fallback.jpg" alt="">
</picture>

Can be written as:

<mediaobject>
  <imageobject>
    <imagedata media="(min-width: 40em)" fileref="big.jpg" pixeldensity="1"/>
    <imagedata media="(min-width: 40em)" fileref="big-hd.jpg" pixeldensity="2"/>
    <imagedata fileref="small.jpg" pixeldensity="1"/>
    <imagedata fileref="small-hd.jpg" pixeldensity="2"/>
    <imagedata fileref="fallback.jpg"/>
  </imageobject>
</mediaobject>

If there is consensus about this approach I can write down more precise spec and provide more examples.

@ndw

This comment has been minimized.

Copy link
Contributor Author

@ndw ndw commented Apr 11, 2017

Yes. I think I ran aground in my investigation because there was no obvious place to hang the media and other attributes. I suppose adding them to imagedata is a plausible answer.

@kosek

This comment has been minimized.

Copy link
Contributor

@kosek kosek commented May 17, 2017

At the latest TC meeting there have been request to draft this solution also using multimediaparam element. Example above would look like:

<mediaobject>
  <imageobject>
    <imagedata fileref="big.jpg">
      <multimediaparam name="media" value="(min-width: 40em)"/>
      <mutlimediaparam name="pixeldensity" value="1"/>
    </imagedata>
    <imagedata fileref="big-hd.jpg">
      <multimediaparam name="media" value="(min-width: 40em)"/>
      <mutlimediaparam name="pixeldensity" value="2"/>      
    </imagedata>
    <imagedata fileref="small.jpg">
      <mutlimediaparam name="pixeldensity" value="1"/>
    </imagedata>
    <imagedata fileref="small-hd.jpg">
      <mutlimediaparam name="pixeldensity" value="2"/>
    </imagedata>
    <imagedata fileref="fallback.jpg"/>
  </imageobject>
</mediaobject>

There was also question how to differentiate between images targeted for web and PDF output. Unofficial but widely used solution for this is to use role attribute on imageobject, see e.g.: http://www.sagehill.net/docbookxsl/GraphicSelection.html#SelectByFormat

We can standardize usage of already existing outputformat attribute for this, it's something like deliverytarget attribute in DITA.

@kosek

This comment has been minimized.

Copy link
Contributor

@kosek kosek commented Jun 11, 2017

DocBook TC decided to go with the later proposal (multimediaparam). Change has been implemented in 5.2b02 schema (see #92)

@kosek kosek closed this Jun 11, 2017
@kosek kosek reopened this Jun 11, 2017
@kosek kosek closed this Mar 14, 2018
@ndw

This comment has been minimized.

Copy link
Contributor Author

@ndw ndw commented Mar 22, 2018

Can you say a little bit more about the processing expectations? It appears that multiple imagedata elements that have the same value for the "media" multimediaparam are grouped together. Are there any other grouping rules? Is order significant?

@ndw ndw reopened this Mar 22, 2018
@kosek

This comment has been minimized.

Copy link
Contributor

@kosek kosek commented Mar 22, 2018

Processing expectations are the same as of original proposal based on dedicated attributes instead of multimediaparam. Order of grouped elements should match original imagedata elements, at least order of first imagedate element that creates new group.

I intended to write implementation for this and write content for TDG but that fall through the cracks. Sorry.

@ndw

This comment has been minimized.

Copy link
Contributor Author

@ndw ndw commented Mar 23, 2018

Ah, thanks. I'll take a stab at implementation and drafting prose. And creating a 5.2 version of TDG.

@bachlipp

This comment has been minimized.

Copy link

@bachlipp bachlipp commented Jan 21, 2020

I do not really get the current state of work already done regarding my suggestion—sorry for asking. So may I kindly ask whether in addition to the updated schema there is already a stylesheet that supports transforming multimediaparam to srcsets in img tags and if so, is this in the 1.0 or 2.0 branch of the DocBook XSL stylesheets? If there are such stylesheets I'd be more than happy to try them and share feedback.

@ndw

This comment has been minimized.

Copy link
Contributor Author

@ndw ndw commented Jan 21, 2020

Alas, I don't think I ever got back to this. But I've made a TODO for it for next time I carve out time to do DocBook stylesheet work. I'll be implementing it in the 2.0 stylesheets.

@bachlipp

This comment has been minimized.

Copy link

@bachlipp bachlipp commented Jan 24, 2020

Thank you very much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.