Fossy-Cats / Git-Buch_EN

English translation of "Das Git-Buch" (The Git Book)
https://git.io/gitbook
Other
1 stars 0 forks source link

Diagrams: Cairo SVG Enforcing Document Sizes? #13

Open tajmone opened 3 years ago

tajmone commented 3 years ago

I've noticed that in the Diagrams README (Markdown) the SVG images generated via the Cairo SVG format tend to have specific sizes, whereas before they where shown as large as the page would allow them to.

This seems to indicate that Cairo SVG adds size info to the generated SVG images.

We need to check if this can be a problem in some output formats, and whether in the HTML edition we can simply enforce custom sizes by specifying a width percentage value relative to the contents width.

If not, we might have to enforce some document size in the source Dia projects, and devise a way to preserve some rational proportions between the various diagrams.

Here's the difference, where the first image is in the Cairo SVG format:

default SVG

and the second one in the default Dia SVG format used before:

Cairo SVG

As you can see, the former doesn't stretch to occupy the full available width, while the latter does.

Currently, the AsciiDoc book enforces custom width values on the images, so it's hard to tell whether the SVG diagrams are stretching beyond their predefined sizes; so we'll need to carry out some tests to evaluate the situation and whether we can safely control the diagrams' widths using relative values (page percentage) or not.

tajmone commented 3 years ago

A first glance at the above diagram in the generated HTML book seems to indicate that AsciiDoc allows us to control the SVGs' effective size by custom width settings, for the above diagram (Figure 6 in the book) is clearly wider than the Cairo SVG image shown in markdown.

In the book source, the diagram is set to scale to 80%:

.Repository Content
image::repository-content.svg[id="fig.repository-content",scaledwidth="80%",width="80%"]

which from the preview document seems to indicate that any size info embedded in the original SVG is being overridden by the custom value shown above.

I'm not sure if the same applies to all other output formats (PDF, etc.).


References