Skip to content
Snippets Groups Projects
New look: Off

Unwanted space around html font tags with svg output

    • Open Issue created by Robin Moussu @robinmoussu

    Steps to reproduce

    Any html label with font color specification. For example:

    digraph {
   main [
       label=<<font color='red'>main</font>( _1: <font color='darkgreen'>impl Fn()</font>, _2: <font color='darkgreen'>usize</font> )>
   ]
}

    Expected output

    This is what you get with

    dot -Tpng my_file.dot
dot -Txlib my_file.dot

    image

    Actual behaviour

    This is what you get with

    dot -Tsvg my_file.dot

    image

    The difference is subtile, but there are extra spaces between main and the opening parenthesis, as well as between Fn() and the comma, and between usize and the closing parenthesis.

    OS Version

    Archlinux, up-to-date

    Graphviz Version

    $ dot -V
dot - graphviz version 2.44.1

    Additional info

    I discussed it on the forum and the bug was reproducible.

    Edited

    Designs

      Child items ...

      2. Activity

      • Robin Moussu changed the description

        changed the description

      • Stephen C. North
        Stephen C. North @truenorth ·
        Owner

        We could embed a generic warning in the generated SVG.

      • Mark Hansen
        Mark Hansen @markhnsn ·
        Owner

        I wonder if this is just fonts or if we are accidentally emitting extra whitespace. The extra spacing looks possibly more than what a font being present or not would account for

      • David VandeBunte
        David VandeBunte @davidvandebunte ·

        I'm running into this same issue, but I can't use the workaround because the addition of cairo also breaks the insertion of clickable URLs into the SVG. For now I'm going to avoid using HTML-like labels to keep clickable links.

      • steve roush
        steve roush @steveroush ·
        Maintainer

        This seems to be a font-sizing problem - Graphviz uses one font to determine text dimensions then SVG uses a different font (or different implementation) to display the text. (see https://forum.graphviz.org/t/unwanted-space-around-html-font-tags/460 and https://forum.graphviz.org/t/how-does-graphviz-calculate-the-length-and-width-of-the-text/1301/7)
        Here is program that creates nodes using many different fonts (but the same text strings). Try it and see if you can find a font that works for you. Note that different browsers and different OSs produce different results.

        digraph {
  rankdir=LR
  node [label=""  shape=rect]
  subgraph cluster1 { label="arial"
    node [fontname="arial"]
    n1 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster2 { label="Arial"
    node [fontname="Arial"]
    n2 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster3 { label="Arial Black"
    node [fontname="Arial Black"]
    n3 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster4 { label="Arial-Bold"
    node [fontname="Arial-Bold"]
    n4 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster5 { label="AvantGarde-Book"
    node [fontname="AvantGarde-Book"]
    n5 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster6 { label="AvantGarde-BookOblique"
    node [fontname="AvantGarde-BookOblique"]
    n6 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster7 { label="AvantGarde-Demi"
    node [fontname="AvantGarde-Demi"]
    n7 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster8 { label="AvantGarde-DemiOblique"
    node [fontname="AvantGarde-DemiOblique"]
    n8 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster9 { label="Bitstream Vera Sans"
    node [fontname="Bitstream Vera Sans"]
    n9 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster10 { label="Bookman-Demi"
    node [fontname="Bookman-Demi"]
    n10 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster11 { label="Bookman-DemiItalic"
    node [fontname="Bookman-DemiItalic"]
    n11 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster12 { label="Bookman-Light"
    node [fontname="Bookman-Light"]
    n12 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster13 { label="Bookman-LightItalic"
    node [fontname="Bookman-LightItalic"]
    n13 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster14 { label="calibri"
    node [fontname="calibri"]
    n14 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster15 { label="Courier"
    node [fontname="Courier"]
    n15 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster16 { label="Courier-Bold"
    node [fontname="Courier-Bold"]
    n16 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster17 { label="Courier-BoldOblique"
    node [fontname="Courier-BoldOblique"]
    n17 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster18 { label="Courier New"
    node [fontname="Courier New"]
    n18 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster19 { label="Courier New Courier"
    node [fontname="Courier New Courier"]
    n19 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster20 { label="Courier New Courier"
    node [fontname="Courier New Courier"]
    n20 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster21 { label="Courier New Courier"
    node [fontname="Courier New Courier"]
    n21 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster22 { label="Courier-Oblique"
    node [fontname="Courier-Oblique"]
    n22 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster23 { label="DejaVu Sans Bold"
    node [fontname="DejaVu Sans Bold"]
    n23 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster24 { label="DejaVu Sans Mono Bold"
    node [fontname="DejaVu Sans Mono Bold"]
    n24 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster25 { label="DejaVu Sans Mono Book"
    node [fontname="DejaVu Sans Mono Book"]
    n25 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster26 { label="doxfont"
    node [fontname="doxfont"]
    n26 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster27 { label="helvetica"
    node [fontname="helvetica"]
    n27 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster28 { label="helvetica"
    node [fontname="helvetica"]
    n28 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster29 { label="Helvetica"
    node [fontname="Helvetica"]
    n29 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster30 { label="HelveticaArialsans-serif"
    node [fontname="HelveticaArialsans-serif"]
    n30 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster31 { label="HelveticaArialsans-serif"
    node [fontname="HelveticaArialsans-serif"]
    n31 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster32 { label="helvetica-bold"
    node [fontname="helvetica-bold"]
    n32 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster33 { label="Helvetica-Bold"
    node [fontname="Helvetica-Bold"]
    n33 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster34 { label="Helvetica-BoldOblique"
    node [fontname="Helvetica-BoldOblique"]
    n34 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster35 { label="Helvetica:italic"
    node [fontname="Helvetica:italic"]
    n35 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster36 { label="Helvetica-Narrow"
    node [fontname="Helvetica-Narrow"]
    n36 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster37 { label="Helvetica-Narrow-Bold"
    node [fontname="Helvetica-Narrow-Bold"]
    n37 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster38 { label="Helvetica-Narrow-BoldOblique"
    node [fontname="Helvetica-Narrow-BoldOblique"]
    n38 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster39 { label="Helvetica-Narrow-Oblique"
    node [fontname="Helvetica-Narrow-Oblique"]
    n39 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster40 { label="Helvetica-Oblique"
    node [fontname="Helvetica-Oblique"]
    n40 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster41 { label="Helvetica-Outline"
    node [fontname="Helvetica-Outline"]
    n41 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster42 { label="Inconsolata"
    node [fontname="Inconsolata"]
    n42 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster43 { label="Lato"
    node [fontname="Lato"]
    n43 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster44 { label="monospace"
    node [fontname="monospace"]
    n44 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster45 { label="Monospace"
    node [fontname="Monospace"]
    n45 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster46 { label="NewCenturySchlbk-Bold"
    node [fontname="NewCenturySchlbk-Bold"]
    n46 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster47 { label="NewCenturySchlbk-BoldItalic"
    node [fontname="NewCenturySchlbk-BoldItalic"]
    n47 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster48 { label="NewCenturySchlbk-Italic"
    node [fontname="NewCenturySchlbk-Italic"]
    n48 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster49 { label="NewCenturySchlbk-Roman"
    node [fontname="NewCenturySchlbk-Roman"]
    n49 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster50 { label="NotoColorEmojis"
    node [fontname="NotoColorEmojis"]
    n50 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster51 { label="Palatino-Bold"
    node [fontname="Palatino-Bold"]
    n51 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster52 { label="Palatino-BoldItalic"
    node [fontname="Palatino-BoldItalic"]
    n52 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster53 { label="Palatino-Italic"
    node [fontname="Palatino-Italic"]
    n53 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster54 { label="Palatino-Roman"
    node [fontname="Palatino-Roman"]
    n54 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster55 { label="sans"
    node [fontname="sans"]
    n55 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster56 { label="Sans-Serif"
    node [fontname="Sans-Serif"]
    n56 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster57 { label="SVN-Avo"
    node [fontname="SVN-Avo"]
    n57 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster58 { label="Symbol"
    node [fontname="Symbol"]
    n58 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster59 { label="Times-Bold"
    node [fontname="Times-Bold"]
    n59 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster60 { label="Times-BoldItalic"
    node [fontname="Times-BoldItalic"]
    n60 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster61 { label="Times-Italic"
    node [fontname="Times-Italic"]
    n61 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster62 { label="Times-Roman"
    node [fontname="Times-Roman"]
    n62 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster63 { label="verdana"
    node [fontname="verdana"]
    n63 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster64 { label="ZapfChancery-MediumItalic"
    node [fontname="ZapfChancery-MediumItalic"]
    n64 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
  subgraph cluster65 { label="ZapfDingbats"
    node [fontname="ZapfDingbats"]
    n65 [ label=<<font color="red">abcdefghijklmnopqrstuvwxyz</font>ABCDEFGHIJKLMNOPQRSTUVWXYZ<font color="green">12345</font>>]
}
}
      • Matthew Fernandez
        Matthew Fernandez @smattr ·
        Owner

        I can't repro this. -Tsvg and -Tsvg:cairo give different output, but both of them display correctly for me (Fedora Linux 36). @magjac, on the forum thread you said you can repro. Is this then OS-specific?

      • Magnus Jacobsson
        Magnus Jacobsson @magjac ·
        Owner

        Yes, and I can still repo this on the current main with -Tsvg (still ok with -Tsvg:cairo):

        $ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 22.04.1 LTS
Release:	22.04
Codename:	jammy
$ uname -a
Linux t440 5.15.0-47-generic #51-Ubuntu SMP Thu Aug 11 07:51:15 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
$ git log -1
commit 3f762d8764d2b09cdbf0a636170a3e2ca7bb3f20 (HEAD, graphviz/main, graphviz/HEAD, main)
Merge: c810fc4df 929b72991
Author: Magnus Jacobsson <magnus.jacobsson@berotec.se>
Date:   Tue Sep 6 20:28:48 2022 +0000

    Merge branch 'add-test-case-for-issue-372' into 'main'
    
    Add edge and node overlap test case for issue #372
    
    See merge request graphviz/graphviz!2824
$ dot -V
dot - graphviz version 6.0.0~dev.20220906.2028 (20220906.2028)
$ dot -Tsvg  ~/Documents/help-460.dot > help-460.svg
$ cat help-460.svg 
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
 "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<!-- Generated by graphviz version 6.0.0~dev.20220906.2028 (20220906.2028)
 -->
<!-- Pages: 1 -->
<svg width="242pt" height="44pt"
 viewBox="0.00 0.00 242.00 44.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 40)">
<polygon fill="white" stroke="none" points="-4,4 -4,-40 238,-40 238,4 -4,4"/>
<!-- main -->
<g id="node1" class="node">
<title>main</title>
<text text-anchor="start" x="8" y="-15.3" font-family="Times,serif" font-size="14.00" fill="red">main</text>
<text text-anchor="start" x="44" y="-15.3" font-family="Times,serif" font-size="14.00">( _1: </text>
<text text-anchor="start" x="79" y="-15.3" font-family="Times,serif" font-size="14.00" fill="darkgreen">impl Fn()</text>
<text text-anchor="start" x="145" y="-15.3" font-family="Times,serif" font-size="14.00">, _2: </text>
<text text-anchor="start" x="179" y="-15.3" font-family="Times,serif" font-size="14.00" fill="darkgreen">usize</text>
<text text-anchor="start" x="216" y="-15.3" font-family="Times,serif" font-size="14.00"> )</text>
</g>
</g>
</svg>
        • Magnus Jacobsson
          Magnus Jacobsson @magjac ·
          Owner

          I created a small test case using Graphviz as library and then I get the correct result:

          <?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
 "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<!-- Generated by graphviz version 6.0.0~dev.20220906.2028 (20220906.2028)
 -->
<!-- Pages: 1 -->
<svg width="200pt" height="44pt"
 viewBox="0.00 0.00 200.14 44.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 40)">
<polygon fill="white" stroke="none" points="-4,4 -4,-40 196.14,-40 196.14,4 -4,4"/>
<!-- main -->
<g id="node1" class="node">
<title>main</title>
<text text-anchor="start" x="8" y="-14.8" font-family="Times,serif" font-size="14.00" fill="red">main</text>
<text text-anchor="start" x="35.99" y="-14.8" font-family="Times,serif" font-size="14.00">( _1: </text>
<text text-anchor="start" x="65.54" y="-14.8" font-family="Times,serif" font-size="14.00" fill="darkgreen">impl Fn()</text>
<text text-anchor="start" x="118.82" y="-14.8" font-family="Times,serif" font-size="14.00">, _2: </text>
<text text-anchor="start" x="147.21" y="-14.8" font-family="Times,serif" font-size="14.00" fill="darkgreen">usize</text>
<text text-anchor="start" x="175.98" y="-14.8" font-family="Times,serif" font-size="14.00"> )</text>
</g>
</g>
</svg>

          The diff is:

          7,8c7,8
< <svg width="242pt" height="44pt"
<  viewBox="0.00 0.00 242.00 44.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
---
> <svg width="200pt" height="44pt"
>  viewBox="0.00 0.00 200.14 44.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
10c10
< <polygon fill="white" stroke="none" points="-4,4 -4,-40 238,-40 238,4 -4,4"/>
---
> <polygon fill="white" stroke="none" points="-4,4 -4,-40 196.14,-40 196.14,4 -4,4"/>
14,19c14,19
< <text text-anchor="start" x="8" y="-15.3" font-family="Times,serif" font-size="14.00" fill="red">main</text>
< <text text-anchor="start" x="44" y="-15.3" font-family="Times,serif" font-size="14.00">( _1: </text>
< <text text-anchor="start" x="79" y="-15.3" font-family="Times,serif" font-size="14.00" fill="darkgreen">impl Fn()</text>
< <text text-anchor="start" x="145" y="-15.3" font-family="Times,serif" font-size="14.00">, _2: </text>
< <text text-anchor="start" x="179" y="-15.3" font-family="Times,serif" font-size="14.00" fill="darkgreen">usize</text>
< <text text-anchor="start" x="216" y="-15.3" font-family="Times,serif" font-size="14.00"> )</text>
---
> <text text-anchor="start" x="8" y="-14.8" font-family="Times,serif" font-size="14.00" fill="red">main</text>
> <text text-anchor="start" x="35.99" y="-14.8" font-family="Times,serif" font-size="14.00">( _1: </text>
> <text text-anchor="start" x="65.54" y="-14.8" font-family="Times,serif" font-size="14.00" fill="darkgreen">impl Fn()</text>
> <text text-anchor="start" x="118.82" y="-14.8" font-family="Times,serif" font-size="14.00">, _2: </text>
> <text text-anchor="start" x="147.21" y="-14.8" font-family="Times,serif" font-size="14.00" fill="darkgreen">usize</text>
> <text text-anchor="start" x="175.98" y="-14.8" font-family="Times,serif" font-size="14.00"> )</text>
        • Matthew Fernandez
          Matthew Fernandez @smattr ·
          Owner

          Do you know any reasons why these two workflows would produce different results?

        • Magnus Jacobsson
          Magnus Jacobsson @magjac ·
          Owner

          Not yet, but I've just started to try to figure it out.

        • Please register or sign in to reply
      • Stephen C. North
        Stephen C. North @truenorth ·
        Owner

        To clarify, generally someone is only going to see this mismatch when graphviz -Tsvg:core output is generated on one computer, then viewed on another computer that has different fonts.

        It could occur even when viewing the generated SVG on the same computer, if the renderer does not access the same fonts as Graphviz, or interprets font names differently than graphviz. (By graphviz, we include the underlying libraries like cairopango and freetype or quartz that perform this for graphviz.)

        Two minor notes:

        1. If you look at the specs, basic SVG isn't intended to nail down text layout.

        2. Cairopango SVG output gets around this by encoding font glyphs as SVG shapes, but it's a lot of complication. The graphviz core SVG generator (essentially a bunch of printfs that we wrote ourselves) isn't capable of that.

        • Magnus Jacobsson
          Magnus Jacobsson @magjac ·
          Owner

          The problem does not occur when viewing the file. It occurs when generating it as you can see above. Running in verbose mode shows this difference on stdout when grepping for "font":

          < fontname: "Times-Roman" resolved to: [internal hard-coded]
> fontname: "Times-Roman" resolved to: (ps:pango  DejaVu Serif, ) (PangoCairoFcFont) "DejaVu Serif 14" 
< <text text-anchor="start" x="8" y="-14.8" font-family="Times,serif" font-size="14.00" fill="red">main</text>
< <text text-anchor="start" x="35.99" y="-14.8" font-family="Times,serif" font-size="14.00">( _1: </text>
< <text text-anchor="start" x="65.54" y="-14.8" font-family="Times,serif" font-size="14.00" fill="darkgreen">impl Fn()</text>
< <text text-anchor="start" x="118.82" y="-14.8" font-family="Times,serif" font-size="14.00">, _2: </text>
< <text text-anchor="start" x="147.21" y="-14.8" font-family="Times,serif" font-size="14.00" fill="darkgreen">usize</text>
< <text text-anchor="start" x="175.98" y="-14.8" font-family="Times,serif" font-size="14.00"> )</text>
> <text text-anchor="start" x="8" y="-15.3" font-family="Times,serif" font-size="14.00" fill="red">main</text>
> <text text-anchor="start" x="44" y="-15.3" font-family="Times,serif" font-size="14.00">( _1: </text>
> <text text-anchor="start" x="79" y="-15.3" font-family="Times,serif" font-size="14.00" fill="darkgreen">impl Fn()</text>
> <text text-anchor="start" x="145" y="-15.3" font-family="Times,serif" font-size="14.00">, _2: </text>
> <text text-anchor="start" x="179" y="-15.3" font-family="Times,serif" font-size="14.00" fill="darkgreen">usize</text>
> <text text-anchor="start" x="216" y="-15.3" font-family="Times,serif" font-size="14.00"> )</text>

          internal hard-coded is looks ok for me, but ps:pango DejaVu Serif, ) (PangoCairoFcFont) "DejaVu Serif 14 does not.

          Edited by Magnus Jacobsson
        • Stephen C. North
          Stephen C. North @truenorth ·
          Owner

          I’m sorry, I didn’t pay enough attention to what you were saying.

          Is the point that -Tsvg:core and -Tsvg:cairo can bind different fonts?

          ...

          On Sep 9, 2022, at 11:35 AM, Magnus Jacobsson (@magjac) gitlab@mg.gitlab.com wrote:

          Magnus Jacobsson https://gitlab.com/magjac commented #1891 (comment 1095050259):

          The problem does not occur when viewing the file. It occurs when generating it as you can see above. Running in verbose mode shows this difference:

          < fontname: "Times-Roman" resolved to: [internal hard-coded]

          fontname: "Times-Roman" resolved to: (ps:pango DejaVu Serif, ) (PangoCairoFcFont) "DejaVu Serif 14" < main < ( _1: < impl Fn() < , _2: < usize < ) main ( _1: impl Fn() , _2: usize ) internal hard-coded is looks ok for me, but ps:pango DejaVu Serif, ) (PangoCairoFcFont) "DejaVu Serif 14 does not. — Reply to this email directly or view it on GitLab #1891 (comment 1095050259). You're receiving this email because of your account on gitlab.com https://gitlab.com/. Unsubscribe https://gitlab.com/-/sent_notifications/REDACTED/unsubscribe from this thread · Manage all notifications https://gitlab.com/-/profile/notifications · Help https://gitlab.com/help

        • Magnus Jacobsson
          Magnus Jacobsson @magjac ·
          Owner

          Not in the latest difference I reported. Cairo is not involved there. The core renderer is used in both cases. The only difference is that in one case I use the dot program and in the other a small tests case using Graphviz as a library. They should give the same result, but don't. My guess is that dot does something that causes the DejaVu font to be found, while my test program doesn't and falls back to "internal hard-coded", whatever that is.

          The dot version looks bad with eog but correct with Firefox while the test program version looks good with eog and bad with Firefox, but instead of extra space, there's too little space:

          image

          So when I said that the problem does not occur when viewing the file, I was not entirely correct. Of course you don't experience the problem until you view the file, but here we have two ways to render the graph that gives different SVG that views good or bad depending on which font the program that views it uses.

          In my case, eog does not seem to find the DejaVu font and therefore shows the SVG generated using the DejaVu font badly, while showing the one with the "internal hard-coded" fine. Firefox does find the DejaVu font and therefore does the opposite.

        • Matthew Fernandez
          Matthew Fernandez @smattr ·
          Owner

          This would also explain why I could not repro this. I was exclusively using Firefox, not realising the outcome was dependent on the viewer as well.

        • Mark Hansen
          Mark Hansen @markhnsn ·
          Owner

          An idea: what if you strace’d the “open” syscalls, you could see what fonts the programs are opening, and if they are different.

          ...

          On Sun, 11 Sep 2022 at 00:49, Matthew Fernandez (@smattr) < gitlab@mg.gitlab.com> wrote:

          Matthew Fernandez https://gitlab.com/smattr commented on a discussion #1891 (comment 1095776114):

          This would also explain why I could not repro this. I was exclusively using Firefox, not realising the outcome was dependent on the viewer as well.

          — Reply to this email directly or view it on GitLab #1891 (comment 1095776114). You're receiving this email because of your account on gitlab.com. Unsubscribe https://gitlab.com/-/sent_notifications/REDACTED/unsubscribe from this thread · Manage all notifications https://gitlab.com/-/profile/notifications · Help https://gitlab.com/help

        • Please register or sign in to reply
        • FeRD (Frank Dana)
          FeRD (Frank Dana) @ferdnyc ·
          Contributor

          I ran into a version of this with the Graphviz Visual Editor.

          It can be somewhat tricky to reproduce, because...

          1. It does depend on the font selected
          2. And the font used (not always the same thing)
          3. BUT not in the ways you'd think

          What I mean by that is, it's often the case that Graphviz is using the same font for layout that's embedded in the SVG, but it still places text in positions that cause problems with other SVG renderers.

          For example, using the following graph definition:

          graph G {
  rankdir="TB";
  n [fontname="Times-Roman" label=<Wow, <i>some</i> other <u>styled</u> text>];
  m [fontname="DejaVu Serif" label=<Wow, <i>some</i> other <u>styled</u> text>];
  o [fontname="Times" label=<Wow, <i>some</i> other <u>styled</u> text>];
  p [fontname="DejaVu Serif" label=<Wow, <i>some</i> other <u>styled</u> text>];
  n -- m -- o -- p;
}

          running it through dot -v -Tsvg reveals that on my system, it selects "DejaVu Serif" for the "Times-Roman" font; as a result, unsurprisingly, the x coordinates of all of the text boxes for the first, second, and fourth nodes are exactly identical; only node 'o' is laid out differently (having named "Times" as the font, which selects "Nimbus Roman" on my system):

          $ dot -v -Tsvg /tmp/sometext2.gv
[...]
fontname: "Times-Roman" resolved to: (ps:pango  DejaVu Serif,  REGULAR) (PangoCairoFcFont) "DejaVu Serif 14" 
fontname: "DejaVu Serif" resolved to: (PangoCairoFcFont) "DejaVu Serif 14" 
fontname: "Times" resolved to: (PangoCairoFcFont) "Nimbus Roman, 14" 
[...]

          But when rendered by most SVG renderers, with DejaVu Serif being an available font, the spacing in the second node (the one that actually uses "DejaVu Serif" in the SVG <text> tags) will be incorrect. Here's an only-slightly-modified version of the SVG output from that operation:

          sometext2-modified.svg

          From <text x= y=>...</text><text x= y=>...</text> to <text x= y=><tspan>...</tspan></text>

          Modified how? Well, I hand-edited the SVG code for the fourth node (that's why I created two identical ones), changing it from this:

          <!-- p -->
<g id="node4" class="node">
<title>p</title>
<ellipse fill="none" stroke="black" cx="153.27" cy="-18" rx="153.27" ry="18"/>
<text text-anchor="start" x="52.02" y="-14.32" font-family="DejaVu Serif" font-size="14.00">Wow, </text>
<text text-anchor="start" x="93.27" y="-14.32" font-family="DejaVu Serif" font-style="italic" font-size="14.00">some</text>
<text text-anchor="start" x="130.77" y="-14.32" font-family="DejaVu Serif" font-size="14.00"> other </text>
<text text-anchor="start" x="178.02" y="-14.32" font-family="DejaVu Serif" text-decoration="underline" font-size="14.00">styled</text>
<text text-anchor="start" x="221.52" y="-14.32" font-family="DejaVu Serif" font-size="14.00"> text</text>
</g>

          to this:

          <!-- p -->
<g id="node4" class="node">
<title>p</title>
<ellipse fill="none" stroke="black" cx="153.27" cy="-18" rx="153.27" ry="18"/>
<text text-anchor="start" x="52.02" y="-14.32" font-family="DejaVu Serif" font-size="14.00" font-stretch="normal" font-style="normal" font-variant="normal" style="white-space:pre"><tspan font-family="DejaVu Serif" font-size="14.00">Wow, </tspan><tspan font-family="DejaVu Serif" font-style="italic" font-size="14.00">some</tspan><tspan font-family="DejaVu Serif" font-size="14.00"> other </tspan><tspan font-family="DejaVu Serif" text-decoration="underline" font-size="14.00">styled</tspan><tspan font-family="DejaVu Serif" font-size="14.00"> text</tspan></text>
</g>

          That's why, no matter what your renderer shows for the first two nodes, the text in the fourth one should all be spaced properly according to the metrics of whatever font is being used to render it.

          Here's a wrapped version of the source for readability, though in the code it needs to be all one line precisely because it's using white-space:pre to preserve the space characters:

          <!-- p -->
<g id="node4" class="node">
<title>p</title>
<ellipse fill="none" stroke="black" cx="153.27" cy="-18" rx="153.27" ry="18"/>
<text text-anchor="start" x="52.02" y="-14.32" font-family="DejaVu Serif" font-size="14.00" 
font-stretch="normal" font-style="normal" font-variant="normal" style="white-space:pre">
<tspan font-family="DejaVu Serif" font-size="14.00">Wow, </tspan>
<tspan font-family="DejaVu Serif" font-style="italic" font-size="14.00">some</tspan>
<tspan font-family="DejaVu Serif" font-size="14.00"> other </tspan>
<tspan font-family="DejaVu Serif" text-decoration="underline" font-size="14.00">styled</tspan>
<tspan font-family="DejaVu Serif" font-size="14.00"> text</tspan>
</text>
</g>

          There's just a single <text> tag that sets the x/y coordinates of the start of the text line, and applies the CSS white-space:pre property to the enclosed text. Then all of the text inside it is styled using <tspan> tags that don't force positioning, they just allow the text to be laid out according to the font metrics.

          The designers of SVG understood that font replacement would make sizing text unreliable, so they designed the <tspan> tag to make style adjustments without resetting the text flow, just like in HTML. Graphviz's SVG renderers never use it, only <text> tags with explicit x and y positions, which is why text so frequently lays out incorrectly.

          Internal drawing routines

          dot's own -Tpng mode never has these issues, but that's because it cheats: the default PNG renderer is usually -Tpng:cairo:cairo, which just like -Tsvg:cairo:cairo will position and draw each individual glyph graphically based on whatever weird notion of font metrics its internal font-layout system uses. That's fine if you're generating a PNG, but as @davidvandebunte discovered, it's no good for SVG because your text isn't text anymore, which means things like hyperlinks (as well as text-selection, copy-paste, etc.) no longer work.

          The SVG source of one of those nodes produced by dot -Tsvg:cairo:cairo, for example, is:

          <g clip-path="url(#clip-0)">
<path fill="none" stroke-width="1" stroke-linecap="butt" stroke-linejoin="miter" stroke="rgb(0%, 0%, 0%)" stroke-opacity="1" stroke-miterlimit="10" d="M 306.546875 -234 C 306.546875 -224.058594 237.925781 -216 153.273438 -216 C 68.621094 -216 0 -224.058594 0 -234 C 0 -243.941406 68.621094 -252 153.273438 -252 C 237.925781 -252 306.546875 -243.941406 306.546875 -234 " transform="matrix(1, 0, 0, 1, 4, 256)"/>
</g>
<g fill="rgb(0%, 0%, 0%)" fill-opacity="1">
<use xlink:href="#glyph-0-0" x="56.023438" y="25.675781"/>
<use xlink:href="#glyph-0-1" x="69.523438" y="25.675781"/>
<use xlink:href="#glyph-0-2" x="77.773438" y="25.675781"/>
<use xlink:href="#glyph-0-3" x="88.273438" y="25.675781"/>
<use xlink:href="#glyph-0-4" x="92.773438" y="25.675781"/>
</g>
<g fill="rgb(0%, 0%, 0%)" fill-opacity="1">
<use xlink:href="#glyph-1-0" x="97.273438" y="25.675781"/>
<use xlink:href="#glyph-1-1" x="104.773437" y="25.675781"/>
<use xlink:href="#glyph-1-2" x="113.023437" y="25.675781"/>
<use xlink:href="#glyph-1-3" x="126.523437" y="25.675781"/>
</g>
<g fill="rgb(0%, 0%, 0%)" fill-opacity="1">
<use xlink:href="#glyph-0-4" x="134.773438" y="25.675781"/>
<use xlink:href="#glyph-0-1" x="139.273438" y="25.675781"/>
<use xlink:href="#glyph-0-5" x="147.523438" y="25.675781"/>
<use xlink:href="#glyph-0-6" x="153.523438" y="25.675781"/>
<use xlink:href="#glyph-0-7" x="162.523438" y="25.675781"/>
<use xlink:href="#glyph-0-8" x="170.773438" y="25.675781"/>
<use xlink:href="#glyph-0-4" x="177.523438" y="25.675781"/>
</g>
<g fill="rgb(0%, 0%, 0%)" fill-opacity="1">
<use xlink:href="#glyph-0-9" x="182.023438" y="25.675781"/>
<use xlink:href="#glyph-0-5" x="189.523438" y="25.675781"/>
<use xlink:href="#glyph-0-10" x="195.523438" y="25.675781"/>
<use xlink:href="#glyph-0-11" x="203.773438" y="25.675781"/>
<use xlink:href="#glyph-0-7" x="208.273438" y="25.675781"/>
<use xlink:href="#glyph-0-12" x="216.523438" y="25.675781"/>
</g>

          The #glyph-N-M refs are defined in the <defs> block as <path> tags; the resulting SVG uses no fonts and contains no textual content.

          Edited by FeRD (Frank Dana)
        • FeRD (Frank Dana)
          FeRD (Frank Dana) @ferdnyc ·
          Contributor

          (To keep text centered in a node, and handle a wider range of font replacements gracefully, using <text text-anchor="middle" x="$x_center_of_node"> might also be a smarter layout choice than setting an explicit x coordinate for the left edge of the text.)

          Edited by FeRD (Frank Dana)
        • Please register or sign in to reply
        • Stephen C. North
          Stephen C. North @truenorth ·
          Owner

          If I can try to summarize: it's commonly recognized when generating and rendering SVG that the generator and the renderer may not have the same fonts, and using <tspan> to change text rendering options within a given text flow allows the resulting errors to accumulate and not interrupt the text layout.

          A difficulty is the graphviz driver is not structured to use that feature. It breaks a text label into text spans and then renders each indepedently, as you noticed.

          Not sure how much effort it would take to rework the driver to handle generate SVG as proposed above.

          Not sure I sympathize with the tone of mild indignation. The behavior of the native SVG generator can be seen in the code for SVG text generation.

          The original code generator was the native Postscript generator. @ellson made a huge leap forward by integrating libgd to generate gif, png and jpeg. This made graphviz usable in web applications. It's just pixels of course, there is no text structure. We used fontconfig to bind font files and freetype to render them. It's not hard to see why cairo decided to bite the bullet and render its own glyphs - even using there's no way to be really sure how the text will render, otherwise.

          Maybe we should have thought more about <tspan> and we talked with Adobe around the time of SVG 1.1 in 2003(?) We didn't understand the issues very well but could realize that text was problematic and they did not want to recreate HTML but were on a slippery slope there. (OpenGL isn't good at text, either.) We were just viewing SVGs in Inkscape or Adobe Illustrator; there was little interest from our user community back then.

          Edited by Stephen C. North
        • John Ellson
          John Ellson @ellson ·
          Owner

          I don't know if this will help, but isn't there a parameter to adjust the padding around the text bounding box? That might give more room for mismatched fonts.

          ...

          On Fri, Nov 8, 2024, 11:21 AM Stephen C. North (@truenorth) < gitlab@mg.gitlab.com> wrote:

          Stephen C. North https://gitlab.com/truenorth commented #1891 (comment 2201557263):

          If I can try to summarize: it's commonly recognized when generating and rendering SVG that the generator and the renderer may not have the same fonts, and using to change text rendering options within a given text flow allows the resulting errors to accumulate and not interrupt the text layout.

          A difficulty is the graphviz driver is not structured to use that feature. It breaks a text label into text spans and then renders each indepedently, as you noticed.

          Not sure how much effort it would take to rework the driver to handle generate SVG as proposed above.

          Not sure I sympathize with the tone of mild indignation. The behavior of the native SVG generator can be seen in the code for SVG text generation https://gitlab.com/graphviz/graphviz/-/blob/main/plugin/core/gvrender_core_svg.c?ref_type=heads#L427 .

          The original code generator was the native Postscript generator. @ellson https://gitlab.com/ellson made a huge leap forward by integrating libgd to generate gif, png and jpeg. This made graphviz usable in web applications. It's just pixels of course, there is no text structure. We used fontconfig to bind font files and freetype to render them. It's not hard to see why cairo decided to bite the bullet and render its own glyphs

          • even using there's no way to be really sure how the text will render, otherwise.

          Maybe we should have thought more about and we talked with Adobe around the time of SVG 1.1 in 2003(?) We didn't understand the issues very well but could realize that text was problematic and they did not want to recreate HTML but were on a slippery slope there. (OpenGL isn't good at text, either.)

          — Reply to this email directly or view it on GitLab #1891 (comment 2201557263). You're receiving this email because you have been mentioned on gitlab.com. Unsubscribe https://gitlab.com/-/sent_notifications/REDACTED/unsubscribe from this thread · Manage all notifications https://gitlab.com/-/profile/notifications · Help https://gitlab.com/help

        • Stephen C. North
          Stephen C. North @truenorth ·
          Owner

          Wait, can this proposal be done in the SVG driver without any API changes? Because the driver can easily find the intended (computed) midpoint of the text, which is all that is needed.

        • John Ellson
          John Ellson @ellson ·
          Owner

          I understand the problem of not knowing the metrics of the fonts in the final rendering, but I m not sure if I'm understanding the specific problem here?

          Textspans can be multiline, with lines separated by \l \n or \r. \n will give ragged left and right edge text blocks. Would that help with centering?

          Or perhaps we should ask Adobe for an interface with a box and a text scan, and have the final renderer scale to fit.

          ...

          On Sun, Nov 10, 2024, 7:56 AM Stephen C. North (@truenorth) < gitlab@mg.gitlab.com> wrote:

          Stephen C. North https://gitlab.com/truenorth commented on a discussion #1891 (comment 2202544006):

          Wait, can this proposal be done in the SVG driver without any API changes? Because the driver can easily find the intended (computed) midpoint of the text, which is all that is needed.

          — Reply to this email directly or view it on GitLab #1891 (comment 2202544006). You're receiving this email because of your account on gitlab.com. Unsubscribe https://gitlab.com/-/sent_notifications/REDACTED/unsubscribe from this thread · Manage all notifications https://gitlab.com/-/profile/notifications · Help https://gitlab.com/help

        • Please register or sign in to reply
      • meator
        meator @meator ·

        This forum post has lead me to this.

        I have conducted some testing inspired by #1891 (comment 1093691808)

        source.dot

        This file is similar to Steve Roush's, I have only added a table (because I was having issues with tables). I have converted the source file to SVG and then used ImageMagick to convert the SVG to PNG (this appeared to be a reliable way to convert it into a portable format that can be observed by you that will preserve the breakage). I did the tests twice, once without having msttcorefonts installed and once with them installed.

        without-msttcorefonts.svg without-msttcorefonts.png with-msttcorefonts.svg with-msttcorefonts.png

        Many of the fonts do not have any padding on the right of the table:

        image

        This is all happening on the same computer. As noted by others, this is not (only) an issue of the viewer.

        This is unfortunate, because pretty much all web-safe fonts in the lists are broken for me in some way or another.

      • Stephen C. North
        Stephen C. North @truenorth ·
        Owner

        Thank you for looking into this.

        It's informative to manually inspect the svg files uploaded above. What you see is that only some of the custom fonts in the graphviz file were resolved to expected fonts. For example, for graphviz the node n14 with font name calibri generates SVG font-family="calibri" and the resulting PNG looks ok. But for a lot of custom graphviz fonts like Palatino-Roman resolve to just the fontconfig backup font-family="Times,serif" so there's no assurance that Graphviz and Imagemagick will find the same thing.

        Although the generated SVG files differ, in SVG you get the same fonts, as shown by this:

        north@margil fontjunk % grep -o 'font-family="[^"]' with-msttcorefonts.svg | grep -o '[^"]$' | sort | uniq > with.txt
north@margil fontjunk % grep -o 'font-family="[^"]' without-msttcorefonts.svg | grep -o '[^"]$' | sort | uniq > without.txt
north@margil fontjunk % diff with.txt without.txt
north@margil fontjunk %

        Instead of using Imagemagick, dot -v -Tpng lists font bindings and shows the internal rendering it is working from.

        As explained elsewhere, there's no guarantee that dot -Tsvg gives results that are consistent across environments or even different programs on the same computer.

        Edited by Stephen C. North
      • Matthew Fernandez
        Matthew Fernandez @smattr ·
        Owner

        Does anyone have an actionable suggestion for resolving this issue? There’s a lot of ink spilled above, and while it all seems constructive it also doesn’t seem to be converging on a solution.

        OTOH I am a ignorant fool who knows only just enough about fonts to be dangerous, but asking for a font the generating machine and/or the target machine do not know surely is never going to end well? Best case scenario, you have an educated guess that includes subjective whitespace problems like the above. To me, this issue seems to be trying to address an inherently unsolvable problem. As Stephen says:

        there's no guarantee that dot -Tsvg gives results that are consistent across environments or even different programs on the same computer.

      • Stephen C. North
        Stephen C. North @truenorth ·
        Owner

        In this post it's claimed that post processing SVG with a tool called nano can solve this problem. But it's not open source or even a tool you can install - it's a website. Its name conflicts with a popular editor! (brew info nano is a different program. Confusing.)

        This article by the nano people (Siemens?) under "Using fonts with Object tags" proposes a way to use CSS like styling with SVG to @impor web fonts. What if graphviz recognized Google API font names and generated those elements.

        This might be more feasible than trying to find the font files that were loaded by pango and generating an embedding a BASE64 representation, like the pangocairo driver does, and more in the spirit of the native SVG driver.

        Edited by Stephen C. North
        • steve roush
          steve roush @steveroush ·
          Maintainer

          There does seem to be a way to improve the svg font selection problem. It is not a "one-size-fits-all" fix, but still a significant improvement for many users.

          This proposal is to add the @face-font svg feature (https://www.w3.org/TR/SVG11/fonts.html#FontFaceElement) as an option to Graphviz svg output. This would allow the end-user to use the same font when displaying an svg file as was used to define the graph. @face-font provides two alternatives:

          • embed the required font file(s) in the svg file
          • provide a link in the svg file to the required font file(s), locally or remotely

          Each alternative has advantages and disadvantages

          • embedding font file(s):

            • font files are large - 50K to 5M bytes, each. a "small" svg file would become much larger with embedding
            • easy to add @font-face embedding to Graphviz (files must be local to the Graphviz system (Fontconfig will not work with remote font files)
            • compression and/or font file "subsetting" can reduce font file size, but requires extra tools
            • works for all end-users: local, web-based, and remote non-web-based

          • link to font-file

            • for local users (svg output generated & used on same computer) link can be to the local font file
            • fontconfig does not seem to be able to use remote font-files (webfonts). These font files would have to be downloaded for fontconfig
            • web-based users can be linked to font files provided by the web server
            • some font files are currently provided by (web-based) font servers (free or fee)
            • remote non-web-based end-users have no access linked font file(s)

          Interestingly, correct @font-face code (linking or embedding) can be successfully inserted into current Graphviz svg output. Not a trivial task, but doable.

          • To determine the fonts and font files used for the sizing step for an input graph
            • add the -v -Gfontnames=ps options to the command line
            • grep the stderr output for the term 'fontname:' or "resolved to'
              • this provides the used font name & font file name
            • fontnames=ps results in correct (or nearly correct) font names in the generated svg (fontnames default value produces SVG fontnames that can't be easily associated with the font used to generate the svg)
            • then text processing the svgfile
              • add the @font-face lines (with links or embedded font files)
              • modify all the '<text' lines
                • to adjust the font name
                • to add font-style, font-stretch, and font-weight terms as needed

          I have a bash/gawk script that does all this, but incorporating it into plugin/core/gvrender_core_svg.c is a much better idea

          Example of a linked font: font_OneNode.Pacifico.ps.linked.svg

          Example of embedded font: font_OneNode.AlexBrush.ps.embedded.svg

        • Mark Hansen
          Mark Hansen @markhnsn ·
          Owner

          Good idea IMO

          ...

          On Sat, 1 Mar 2025 at 12:16, steve roush (@steveroush) gitlab@mg.gitlab.com wrote:

          steve roush https://gitlab.com/steveroush commented #1891 (comment 2373759631):

          There does seem to be a way to improve the svg font selection problem. It is not a "one-size-fits-all" fix, but still a significant improvement for many users.

          This proposal is to add the @face-font svg feature ( https://www.w3.org/TR/SVG11/fonts.html#FontFaceElement) as an option to Graphviz svg output. This would allow the end-user to use the same font when displaying an svg file as was used to define the graph. @face-font provides two alternatives:

          • embed the required font file(s) in the svg file
          • provide a link in the svg file to the required font file(s), locally or remotely

          Each alternative has advantages and disadvantages

          embedding font file(s):

          • font files are large - 50K to 5M bytes, each. a "small" svg file would become much larger with embedding
          • easy to add @font-face embedding to Graphviz (files must be local to the Graphviz system (Fontconfig will not work with remote font files)
            • compression and/or font file "subsetting" can reduce font file size, but requires extra tools
            • works for all end-users: local, web-based, and remote non-web-based

          link to font-file

          • for local users (svg output generated & used on same computer) link can be to the local font file
          • fontconfig does not seem to be able to use remote font-files (webfonts). These font files would have to be downloaded for fontconfig
          • web-based users can be linked to font files provided by the web server
            • some font files are currently provided by (web-based) font servers (free or fee)
            • remote non-web-based end-users have no access linked font file(s)

          Interestingly, correct @font-face code (linking or embedding) can be successfully inserted into current Graphviz svg output. Not a trivial task, but doable.

          • To determine the fonts and font files used for the sizing step for an input graph
            • add the -v -Gfontnames=ps options to the command line
            • grep the stderr output for the term 'fontname:' or "resolved to'
              • this provides the used font name & font file name
            • fontnames=ps results in correct (or nearly correct) font names in the generated svg (fontnames default value produces SVG fontnames that can't be easily associated with the font used to generate the svg)
            • then text processing the svgfile
              • add the @font-face lines (with links or embedded font files)
              • modify all the '<text' lines
                • to adjust the font name
                • to add font-style, font-stretch, and font-weight terms as needed

          I have a bash/gawk script that does all this, but incorporating it into plugin/core/gvrender_core_svg.c is a much better idea

          Example of a linked font: [image: font_OneNode.Pacifico.ps.linked.svg] https://gitlab.com/-/project/4207231/uploads/ab5ae7e03c3fe5857381fadf8d8e2d6b/font_OneNode.Pacifico.ps.linked.svg

          Example of embedded font: [image: font_OneNode.AlexBrush.ps.embedded.svg] https://gitlab.com/-/project/4207231/uploads/40f10f9b1c7227e1228363a112ce78c6/font_OneNode.AlexBrush.ps.embedded.svg

          — Reply to this email directly or view it on GitLab #1891 (comment 2373759631). You're receiving this email because of your account on gitlab.com. Unsubscribe https://gitlab.com/-/sent_notifications/REDACTED/unsubscribe from this thread · Manage all notifications https://gitlab.com/-/profile/notifications · Help https://gitlab.com/help

        • Stephen C. North
          Stephen C. North @truenorth ·
          Owner

          Searched for a library to generate @font-face rules, but found only the npm font-face-generator package. Couldn't find a library that works with fontconfig.

          It seems like textfont_t would be the appropriate place to store a path reference if it is available. Although all this code is quite old, font encapsulation came late (probably around the time when HTML labels were added) so more global cleanup might be needed to get this to work nicely. I think we previously observed that pango/freetype does not provide an API to access font face content, so that would hinder generating inline fonts. Also, I think there's a problem of font encodings and translating between them, which seems to be getting well outside the intended scope of Graphviz itself. (To me, this discussion reveals how much a text based tool that does final text layout is an outlier in the ecosystems we use.)

        • Please register or sign in to reply
      • steve roush
        steve roush @steveroush ·
        Maintainer

        Just noticed that the "Pacifico" example (above) does not display correctly on this page.
        It will display correctly if you "open image in new tab" (really it seems to download the svg file) and then open the downloaded svg file. Cripes.

      • Stephen C. North
        Stephen C. North @truenorth ·
        Owner

        I might work on this.

        Also, implement the suggestion from 2020 to embedded an SVG comment that explains where to find more information about this issue to help more inquisitive people.

      • steve roush
        steve roush @steveroush ·
        Maintainer

        Here is a link to my shell script that uses SVG @font-face:
        https://gist.github.com/steveroush/528f9fde1433d382afd329c2cd0f9d0e

        Note: it is NOT well tested and requires a Linux or Linux-like system (e.g. not Windows cmd)

      Please register or sign in to reply