Images (SVG) always maximally scaled #76
Comments
|
This is what I do in this case: And then in the doc itself: I set the |
|
Also, keep in mind, this is what the scaledwidth attribute is for. It's not super clear, but in general the scaledwidth attribute is for PDF and the width attribute is for HTML5. See https://github.com/asciidoctor/asciidoctor-pdf/blob/master/lib/asciidoctor-pdf/converter.rb#L578 It's very likely we're going to have to think about how to get more fine-grained control because I recognize that we aren't covering all the use cases. |
|
+1. Currently unusable for asciidoctor-diagram. The diagrams require a constant dpi per document (a width in pt is provided in the svg's). |
|
+1. |
|
+1, running into this issue using asciidoctor-diagram to generate svgs. |
|
I'll move this to 1.5.0 since it seems to be a showstopper for more and more users. |
|
It's important to understand that there is a way to control the width of SVGs in PDF. It's just that the name of the attribute is different (and has slightly different semantics). When converting to PDF, you should use the There is one major different with Here's how you would write your image macro so that the SVG is not maximally scaled. That at least addresses the title of this issue, which is that this value cannot be controlled. Now, I realize that we still don't have all the necessary controls, so I'd like to proceed by making sure we have a way to handle the essential use cases for scaling images in the PDF. |
|
Looking at it closer, I now see that scaledwidth doesn't work if width is set when using the DocBook toolchain (a2x, fopub). This should actually be fixed by what we put into the DocBook output...but that's a separate issue. |
You can also check for |
|
I did some testing and it appears that Asciidoctor Diagram will pass through the scaledwidth attribute. Thus, to get a usable result for Asciidoctor PDF, please use: Asciidoctor PDF will ignore the |
|
...and when using SVGs, you are correct that the |
|
I did some more thinking about this in the following thread. http://discuss.asciidoctor.org/Unit-of-measure-for-image-dimensions-tp3040p3222.html I think the solution is that we need width attributes per backend. It's kind of like scaledwidth, except that it's not changing the semantics at the same time. The current width and height attributes in the image block are meant to be metadata only. They communicate to the processor the original rasterized dimensions of the image (or, in the case of SVG, the original viewport). These values are pixels. We then need a way to control the scaling of the image. I propose the following attributes:
These attributes can take a value and a unit (e.g., What do you think about the css and pdf prefixes? Should we use screenwidth and printwidth instead? Any other ideas? |
|
I want to clarify why the code behaves the way it does currently to help you think about a solution. I decided not to honor the What we could do is if |
- use native image width scaled by 75% by default - allow explicit width to be set using pdfwidth attribute - make alt text a link if image cannot be resolved and link attribute is present - align alt text to honor image alignment - add helper method to calculate pt from measurement value (number with units) - don't advance to new page if already at top of page - code cleanups
- use native image width scaled by 75% by default - allow explicit width to be set using pdfwidth attribute - make alt text a link if image cannot be resolved and link attribute is present - align alt text to honor image alignment - add helper methods to convert to pt from string or number - don't advance to new page if already at top of page - code cleanups
|
I've proposed a fix. See #218 The fix does a couple things.
What I have not yet done is scale down the image to fit the page if no width is specified. Perhaps we need a maxwidth attribute (and/or maxpdfwidth). |
|
To align with behavior we added to the listing block, perhaps instead of maxwidth, we should honor the autofit option for this purpose. |
|
To clarify, autofit is assumed to mean scale down in this context, not scale up. |
|
Another option is to scale the image down to fit on the page if only the width attribute is specified. If the pdfwidth attribute is specified, then that value is used as is, even if it makes the image larger than the page. |
- default to native image width scaled by 75% by default - allow explicit width to be set using pdfwidth attribute - enforce max width of 100%, except for pdfwidth or scaledwidth - make alt text a link if image cannot be resolved and link attribute is present - align alt text to honor image alignment - add helper methods to convert to pt from string or number - don't advance to new page if already at top of page - code cleanups and optimizations
|
I decided to implement such that if neither the pdfwidth or scaledwidth attributes are specified, the maximum width of the image is the width of the current bounds / box. The pdfwidth and scaledwidth attributes can be used to override this behavior with an explicit value. |
- default to native image width scaled by 75% by default - allow explicit width to be set using pdfwidth attribute - enforce max width of 100%, except for pdfwidth or scaledwidth - make alt text a link if image cannot be resolved and link attribute is present - align alt text to honor image alignment - add helper methods to convert to pt from string or number - don't advance to new page if already at top of page - code cleanups and optimizations
resolves #76 allow fine-grained control over image width
|
should the scaledwith attribute affect the HTML output as well? Both scaledwidth and pdfwidth (used on their own) appear to scale as expected in the PDF output, but I am not seeing anything in the HTML output to scale the images. Ideally, I want scaledwidth="80%" to scale the image to 80% of the text column width in all output forms. |
Not using You can set a percentage width for HTML using the width attribute. However, technically this produces invalid HTML because as of HTML5, the width value can only be unitless (CSS pixel). We don't currently accommodate percentage scaling any other way in the HTML backend. Something to discuss. |
|
I want to mention that I missed a use case with SVGs. If a width is set in the SVG and it's wider than the page, than the image is not being fit to the page. I didn't realize that Prawn SVG wouldn't handle this case. I've filed a follow-up issue: #242. |
|
I've found that just using |
|
I'm confident that the fix for #242 will address the remaining scaling issues. |
|
I would still be interested in being having landscape pages in the PDF output for wide diagrams that have been made with that intention - which is pretty common. Since some diagrams might simply be wide because they were obtained in some strange way (e.g. very high-res screenshot), there's no way to infer whether a landscape page would be needed or not. Therefore it would have to be indicated explicitly, perhaps in the image macro, e.g. 'landscape'. (proposal moved to #250) The more I think about it, the more I think landscape images with float/nofloat need to be supported in PDFs, as this is extremely common in publishing and documentation. Shall I raise a new issue on that? |
Please do. This is very useful analysis. I like each issue to be very focused on a single task. That gives the task the best chance to be addressed and helps keep the conversation on track. |
Hi there!
asciidoctor-pdf always scales
small_image.svgto fit the width entirely into the pdf.I see this as being ok (it is definitely better than the image-cut-off that one gets with asciidoctor-fopub asciidoctor/asciidoctor-fopub#43) ; but just note: it is not possible to decrease the width, should one like to do this.
Here is sample.adoc that you can test with html5, pdf (via asciidoctor-fopub), pdf (via asciidoctor-pdf)
[depends only of
small_image.svg, that you can copy-paste from below]The scaling does not harmonize nicely between html5 and asciidoctor-fopub.
I believe there should be a possibility to scale to fit the width, but preventing cut-off of an image.
Source of image small_image.svg (for copy-pasting):
The text was updated successfully, but these errors were encountered: