Images as svg #1288

jnavila · 2019-08-08T20:50:28Z

No description provided.

jnavila · 2019-08-08T20:56:12Z

FTR, here is the xslt stylesheet (not clean):

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:svg="http://www.w3.org/2000/svg">
    <xsl:output indent="yes" method="xml"/>

    <xsl:template match="@* | node()">
      <xsl:copy>
        <xsl:apply-templates select="@* | node()"/>
      </xsl:copy>
    </xsl:template>

    <xsl:template match="node()" mode="center">
      <xsl:param name="center_val"/>
      <xsl:copy>
        <xsl:apply-templates select="@* | node()" mode="center">
          <xsl:with-param name="center_val"><xsl:value-of select="$center_val"/></xsl:with-param>
        </xsl:apply-templates>
      </xsl:copy>
    </xsl:template>

    <xsl:template match="@*" mode="center">
      <xsl:param name="center_val"/>
      <xsl:copy>
        <xsl:apply-templates select="@* | node()" mode="center">
          <xsl:with-param name="center_val"><xsl:value-of select="$center_val"/></xsl:with-param>
        </xsl:apply-templates>
      </xsl:copy>
    </xsl:template>

    <xsl:template match="svg:g[svg:rect]">
      <xsl:copy>
        <xsl:apply-templates select="@* | node()" mode="center">
          <xsl:with-param name="center_val">
            <xsl:value-of select="svg:rect/@width div 2"/>
          </xsl:with-param>
        </xsl:apply-templates>
      </xsl:copy>
    </xsl:template>

    <xsl:template match="svg:g[svg:rect]" mode="center">
      <xsl:copy>
        <xsl:apply-templates select="@* | node()" mode="center">
          <xsl:with-param name="center_val">
            <xsl:value-of select="svg:rect/@width div 2"/>
          </xsl:with-param>
        </xsl:apply-templates>
      </xsl:copy>
    </xsl:template>

    <xsl:template match="svg:tspan" mode="center">
      <xsl:param name="center_val"/>
      <xsl:copy>
        <xsl:attribute name="x"><xsl:value-of select="$center_val"/></xsl:attribute>
        <xsl:apply-templates select="@y | node()"/>
      </xsl:copy>
    </xsl:template>

    <xsl:template match="svg:text" mode="center">
      <xsl:param name="center_val"/>
      <xsl:copy>
        <xsl:attribute name="stroke"><xsl:choose><xsl:when test="@stroke"><xsl:value-of select="@stroke"/></xsl:when><xsl:otherwise>#979797</xsl:otherwise></xsl:choose></xsl:attribute>
        <xsl:attribute name="stroke-width">0</xsl:attribute>
        <xsl:attribute name="font-family">Source Code Pro</xsl:attribute>
        <xsl:attribute name="font-size">12px</xsl:attribute>
        <xsl:attribute name="font-weight">900</xsl:attribute>
        <xsl:attribute name="fill"><xsl:choose><xsl:when test="@stroke"><xsl:value-of select="@stroke"/></xsl:when><xsl:otherwise>#979797</xsl:otherwise></xsl:choose></xsl:attribute>
        <xsl:attribute name="fill-opacity">1</xsl:attribute>
        <xsl:attribute name="stroke-width">0</xsl:attribute>
        <xsl:attribute name="text-anchor">middle</xsl:attribute>
        <xsl:apply-templates select="@id | node()" mode="center">
          <xsl:with-param name="center_val">
            <xsl:value-of select="$center_val"/>
          </xsl:with-param>
        </xsl:apply-templates>
      </xsl:copy>
    </xsl:template>

</xsl:stylesheet>

max123kl · 2019-08-09T09:01:00Z

I've only had a closer look at areas.svg so far.
Errors in image areas.svg:
the font in the grey arrows was not changed to "Source Code Pro" (e.g. lines 34, 37 and 40 in the code)
Set the following values there:

stroke-width="0"
font-family="Source Code Pro"
font-size="12px"
font-weight="900"
fill="#FFFFFF"

Don't change the value of fill (better contrast to the arrow below)

The text is not vertically centered, so the descenders of the characters (lowercase g, j, y, etc.) are not within the grey area. I cannot name the exact values for the positions (x=... and y=...).

The values stroke="#979797" and stroke-width="0" can also be replaced by stroke="none".
But only with the letters!
Look at my changed file.

I also came up with another effect.
If the SVG file is opened on a machine that does not have a "Source Code Pro" font installed, the browser will replace the font according to the browser default. You should check if the same happens when PDF's and ePub's are created on such machines.

jnavila · 2019-08-09T09:33:28Z

I've only had a closer look at areas.svg so far.
Errors in image areas.svg:
the font in the grey arrows was not changed to "Source Code Pro" (e.g. lines 34, 37 and 40 in the code)
Set the following values there:
stroke-width="0"
font-family="Source Code Pro"
font-size="12px"
font-weight="900"
fill="#FFFFFF"

Don't change the value of fill (better contrast to the arrow below)

The text is not vertically centered, so the descenders of the characters (lowercase g, j, y, etc.) are not within the grey area. I cannot name the exact values for the positions (x=... and y=...).

Unfortunately, this cannot be done automatically by script. Some final hand polishing will inevitably be needed, typically for SVGs that are not just an assembly of text boxes.

For this one, I think that the export to SVG yields bad results: the size of the arrow heads is wrong.

Changing the font family in batch can still be performed.

The values stroke="#979797" and stroke-width="0" can also be replaced by stroke="none".
But only with the letters!

OK, I will tweak the script a little more.

I also came up with another effect.
If the SVG file is opened on a machine that does not have a "Source Code Pro" font installed, the browser will replace the font according to the browser default. You should check if the same happens when PDF's and ePub's are created on such machines.

This may be an issue, because this font is not present on the git-scm.com web server and we don't want to include it into our PDFs (we use Noto to be sure that we cover all character sets). As the SVG may be translated, it would be safer to use a font for which we have a wide range of symbols available. Remember Progit is translated in quite a number of languages.

For Ebooks, I'm not sure, but I think we cannot impose a font.

Would it be too bad to use Noto here?

max123kl · 2019-08-09T09:45:02Z

Would it be too bad to use Noto here?

I've never seen this font before. Do you have a link, so that we can be sure to talk about the same font?

jnavila · 2019-08-09T09:51:02Z

It's Google's "No Tofu" font:

https://www.google.com/get/noto/

max123kl · 2019-08-09T11:00:53Z

This font is even less suitable than the former "Menlo Mono" font. It has only one (normal) font-weight. In the picture you can see the 12 different samples of the "Source Code Pro".
If the text is to appear as heavy/thick as now, a font must be selected that has a minimum weight of 800 (100=ultra light, 400=normal,regular, 600=bold, 800+=black,ultra bold) .

I installed the "Noto" here – as far as I can see the character-set is equal to the "Source Code Pro", which contains 2.030 characters. Last not least the "Noto" font is in TTF format.

Is there no way to install this font on the server? Useful hints may be found here..

jnavila · 2019-08-09T11:35:35Z

I don't see the same thing for Noto: https://www.google.com/get/noto/#sans-lgc where there are multiple font-weights, with different condensed forms.

ExtraCondensed Thin
ExtraCondensed Thin Italic
ExtraCondensed ExtraLight
ExtraCondensed ExtraLight Italic
ExtraCondensed Light
ExtraCondensed Light Italic
ExtraCondensed Regular
ExtraCondensed Regular Italic
ExtraCondensed Medium
ExtraCondensed Medium Italic
ExtraCondensed SemiBold
ExtraCondensed SemiBold Italic
ExtraCondensed Bold
ExtraCondensed Bold Italic
ExtraCondensed ExtraBold
ExtraCondensed ExtraBold Italic
ExtraCondensed Black
ExtraCondensed Black Italic

in Sans and Serif forms.

Where did you get the Noto font? The ones available on the site are pretty complete. If you download the complete set, that's 1.1GB!

max123kl · 2019-08-09T12:45:11Z

You have linked to Noto Sans and not to Noto Mono. Inside your selection, there is Noto Mono (1 style) mono spaced only.

Compare the width of the letter "i" with the width of the letter "M". With monospaced fonts, the two letters occupy the same space. With propotional fonts, the distance between two letters is optically balanced with so-called "hints", so that the space occupied by a "M" is larger than that of an "i". Reading texts using proportional fonts is more comfortable.

A mono spaced font is requested by Ben.
See : #1158 (comment)
and: #1158 (comment)

On the Google Fonts page you will find the following selection. No single type is heavier than bold.

jnavila · 2019-08-09T13:59:02Z

I'm not sure this is a strong requirement. As I already said, mono fonts don't have extended charsets, so they cannot be used in translation context.

max123kl · 2019-08-09T14:28:23Z

The Menlo Mono is monospaced and was used before in PNG diagrams.

EDIT
When a vector drawing is exported to PNG, a pixel image is created.
Then the text is also converted into pixels – with all the disadvantages you have seen (loss of quality with enlargements, no longer editable, ...). The advantage is that the drawing, as it is, is displayed identically with every viewer. I.e. fonts are virtually embedded.

In vector drawing programs there is a function called "Convert To Paths" or something similar. This function converts letters into shapes. Texts are then no longer easy to edit, but the drawing can then be displayed on any computer, regardless of which fonts are installed.
/EDIT

I always thought a proportional font in this place to be a better choice.

Since I don't understand enough about coding, I followed Ben's argument:

Most of the text in the diagrams is things like SHA-1 hashes, ref names, and the content of blobs, so a monospace font makes sense there.

You would have to decide if monospaced is a MUST or if a proportional font is possible. Regardless of that, I vote for a font in OTF format that offers better features.

ben · 2019-08-09T15:48:03Z

For this one, I think that the export to SVG yields bad results: the size of the arrow heads is wrong.

I'm with you here. This is what the original Sketch export to PNG yielded:

When I open the file in Sketch now, the arrow bodies are narrower, and the heads are wider, and it's pretty bad. It might be possible to fix this with a script, but it also might be just a manual slog. ☹️

Also notable: most of the text in boxes should be white, but it all exported as grey for some reason.

As I already said, mono fonts don't have extended charsets, so they cannot be used in translation context.

As we discussed before though, most of the text in the diagrams is ref names and sha-1 hashes, which don't necessarily need to be translated. What explanatory text there is could easily be set in a different font if Source Code Pro doesn't work for a particular translation project.

My bottom line here is: just convert everything to Source Code Pro. This PR should be a high-level pass at automated fixes, we can hash out the smaller differences in later PRs. We're not trying to make perfect diagrams with this patch, we're just trying to get closer.

max123kl · 2019-08-09T16:39:21Z

When I open the file in Sketch now, the arrow bodies are narrower, and the heads are wider, and it's pretty bad. It might be possible to fix this with a script, but it also might be just a manual slog.

That's quite easy to fix with Inkscape.

Also notable: most of the text in boxes should be white, but it all exported as grey for some reason.

The reason is the wrong value of stroke-width .
As I already wrote above these two values have to be set or better replaced by stroke="none".

The values stroke="#979797" and stroke-width="0" can also be replaced by stroke="none".

Some minutes ago I edited my previous post again. I show a work-around to be independent of the installed fonts and still be able to use the advantages of SVG graphics (See).

jnavila · 2019-08-09T18:28:16Z

I agree that using a monospace font is a widely accepted typographical convention to refer to "source code" things, by contrast with English text. They don't need to be translated. So, the next question is how to embed them into our artifacts. For the other parts of text, let's just stick to a Noto Sans, which is already available.

As for the script, I'm just going to convert every fonts to "Source Code Pro", and change the stroke to none in every text elements.

@max123kl changing fonts to paths will make the files much larger, I'd prefer a solution where we embed the necessary stuff. Plus, once it's converted there's no way back to edition, so this is a kind of compilation.

max123kl · 2019-08-10T16:22:20Z

@ben
I'm a little confused.
Assuming the next two sentences were correct:
The HTML document e.g. https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control still uses the old PNG files.
AND
A PDF, newly downloaded yesterday, uses the 1st version of the SVG files or improved PNG files.

SO
The SVG diagrams from the last commit (#613f337) in the branch filtered_svg have different colors in the texts compared to the PDF and HTML outputs.

Which colors should be displayed in the future?
I think the old color scheme is almost always better than the new version.

I'm asking because I' m currently building the symbols for Inkscape.

Created a PR #1289

jnavila · 2019-08-10T17:25:14Z

Ah... The images on git-scm are static and they may have not been updated for a while. There were also a few commits in order to reduce their size for faster and lighter delivery.
git/git-scm.com@d3e49c7

It may have brought a quality regression.

In the book, the images are still the png.

ben · 2019-08-10T20:41:28Z

A PDF, newly downloaded yesterday, uses the 1st version of the SVG files or improved PNG files.

No source code has been changed to pull in the new SVGs. We'd have to change a line like this one:

image::images/lifecycle.png[The lifecycle of the status of your files.]

…to refer instead to images/lifecycle.svg. I imagine that won't be done until we're happy with the SVG versions.

max123kl · 2019-08-11T08:10:34Z

I have here a backup file of progit2.pdf (downloaded on 2019-07-11), where the images are more blurry than the download from 2019-08-09.
Compare the graph on page 16 (Figure 6. Working tree, staging area, and Git directory).
There's got to be a reason for that.

ben · 2019-08-11T13:40:24Z

That is curious. But the images are still raster, which you can see if you zoom all the way in. There are definite pixels in the images, while the surrounding text is silky smooth. You can also tell because the arrows are the right size. 😁

max123kl · 2019-08-11T17:59:20Z

They may be the first PNG files after changing the font to Roboto Mono.

jnavila · 2019-08-11T18:40:17Z

commit 89522c6 might be the culprit

ben · 2019-08-21T15:42:33Z

✨

jnavila mentioned this pull request Aug 8, 2019

Please make the diagrams with open source tools #1158

Closed

jnavila added 2 commits August 21, 2019 08:33

images: switch font weight to 700

9689ed8

images: change font color in reset-*.svg

d830d5d

sivaraam mentioned this pull request Jul 4, 2020

Change references of 'pu' to 'seen' #1459

Merged

HonkingGoose mentioned this pull request Oct 4, 2020

Switch to asciidoctor 2.0.10 #1373

Closed

jnavila closed this Dec 14, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Images as svg #1288

Images as svg #1288

jnavila commented Aug 8, 2019

jnavila commented Aug 8, 2019

max123kl commented Aug 9, 2019 •

edited

Loading

jnavila commented Aug 9, 2019

max123kl commented Aug 9, 2019

jnavila commented Aug 9, 2019

max123kl commented Aug 9, 2019 •

edited

Loading

jnavila commented Aug 9, 2019

max123kl commented Aug 9, 2019 •

edited

Loading

jnavila commented Aug 9, 2019

max123kl commented Aug 9, 2019 •

edited

Loading

ben commented Aug 9, 2019

max123kl commented Aug 9, 2019 •

edited

Loading

jnavila commented Aug 9, 2019

max123kl commented Aug 10, 2019

jnavila commented Aug 10, 2019

ben commented Aug 10, 2019

max123kl commented Aug 11, 2019 •

edited

Loading

ben commented Aug 11, 2019

max123kl commented Aug 11, 2019

jnavila commented Aug 11, 2019

ben commented Aug 21, 2019

Images as svg #1288

Images as svg #1288

Conversation

jnavila commented Aug 8, 2019

jnavila commented Aug 8, 2019

max123kl commented Aug 9, 2019 • edited Loading

jnavila commented Aug 9, 2019

max123kl commented Aug 9, 2019

jnavila commented Aug 9, 2019

max123kl commented Aug 9, 2019 • edited Loading

jnavila commented Aug 9, 2019

max123kl commented Aug 9, 2019 • edited Loading

jnavila commented Aug 9, 2019

max123kl commented Aug 9, 2019 • edited Loading

ben commented Aug 9, 2019

max123kl commented Aug 9, 2019 • edited Loading

jnavila commented Aug 9, 2019

max123kl commented Aug 10, 2019

jnavila commented Aug 10, 2019

ben commented Aug 10, 2019

max123kl commented Aug 11, 2019 • edited Loading

ben commented Aug 11, 2019

max123kl commented Aug 11, 2019

jnavila commented Aug 11, 2019

ben commented Aug 21, 2019

max123kl commented Aug 9, 2019 •

edited

Loading

max123kl commented Aug 9, 2019 •

edited

Loading

max123kl commented Aug 9, 2019 •

edited

Loading

max123kl commented Aug 9, 2019 •

edited

Loading

max123kl commented Aug 9, 2019 •

edited

Loading

max123kl commented Aug 11, 2019 •

edited

Loading