Custom cursors and high dpi (Windows and MacOS testers needed)

[mikeprice99]

For example, they should all be Plain SVG

I aim to write standards compliant SVG, preferably SVG1.1 for backwards compatibility.

...and have a native resolution of 96 dpi.

There is no resolution specified in SVG. Its a vector format using arbitrary units. It's down to the renderer to decide how to interpret unspecified units. Most browsers convert on 1 unspecified unit = 1 pixel. So browsers are useful for previewing svgs to get an idea of actual size for, in our case, of 64X64pixels. (You can specify units in pixels or points, but again, they are subject to interpretation by the renderer - this is where the confusion between 72dpi and 96dpi gets complicated: adobe and the rest of the world don't agree.)
I've not tested the conversion used in FreeCAD/Qt to create button images, cursors etc yet, but I'll be interested to see if it makes any difference whether I specify width & height or provide a viewBox definition. If I give viewBox definition, browsers will show the svg at maximum resolution, if I give width & height it will interpret the values as pixels.

[vocx]

...
There is no resolution specified in SVG. Its a vector format using arbitrary units. ...

I understand this. However, in versions of Inkscape before 0.91, it would assume a pixel density of 90 dpi. Afterwards, it assumes the CSS standard of 96 dpi. So, if you open many old icons with a modern version of Inskcape, it detects this mismatch and offers you to correct it.

I don't know the internals of SVG with detail, but it seems there is only a place at the beginning where it allows you to set such scale for the page, with the assumption of 90 dpi or 96 dpi for newer Inkscape.

See pull request #3060 and the referenced page, Units in Inkscape. I'm sure you know about this more than I do, so you will do it right.

[vanuan]

I understand this. However, in versions of Inkscape before 0.91, it would assume a pixel density of 90 dpi. Afterwards, it assumes the CSS standard of 96 dpi. So, if you open many old icons with a modern version of Inskcape, it detects this mismatch and offers you to correct it.

I don't know the internals of SVG with detail, but it seems there is only a place at the beginning where it allows you to set such scale for the page, with the assumption of 90 dpi or 96 dpi for newer Inkscape.

It seems to me that the only way inkscape could know about assumed DPI is that it's version is embedded inside the SVG file itself. So newer versions of inkscape works the same with files created with older versions of inkscape. And the offer to convert is just replacing the version embedded in the file.

It doesn't affect plain SVG since inkscape doesn't know anything about author's assumed DPI since the inkscape version is absent in plain SVG

[vanuan]

Speaking of SVG. It seems that some icons have UTF-8 symbols which makes them not being rendered in python toolbars. For example, "Draft_Move.svg" has this line:

Code: Select all

        <dc:description>Four equally sized arrow heads at 90° to each other, all joined at the tail</dc:description>

The degree symbol for some reason makes some corruption in the generated Draft_rc.py file or something like that. I couldn't find any reproduction of this issue on the forum. Maybe it's just a peculiarity of my Linux distro.

[vanuan]

Ah, it's a bug in my implementation of the color replacement.

Code: Select all

    QString stringContents = QString::fromUtf8(originalContents);
    for ( const auto &colorToColor : colorMapping ) {
        ulong fromColor = colorToColor.first;
        ulong toColor = colorToColor.second;
        QString fromColorString = QString::fromLatin1(":#%1;").arg(fromColor, (int)6, (int)16,  QChar::fromLatin1('0'));
        QString toColorString = QString::fromLatin1(":#%1;").arg(toColor, (int)6, (int)16,  QChar::fromLatin1('0'));
        stringContents = stringContents.replace(fromColorString, toColorString);
    }
    QByteArray contents = stringContents.toLatin1();

I should've used "toUtf8". Fixed

[vocx]

It seems to me that the only way inkscape could know about assumed DPI is that it's version is embedded inside the SVG file itself...

It is. Draft's importSVG module actually does some parsing of this value to calculate the scaling of certain shapes.

[vanuan]

The next batch of cursors are hardcoded to View3DInventorViewer:

https://github.com/FreeCAD/FreeCAD/blob ... #L167-L224

They have quite a peculiar format. It's a monocolored image with 1 bit per pixel (Format_MonoLSB) and a mask which makes some parts transparent. It's a 16x16 (256) image packed into 46 bytes out which only the first 24 are filled (22 bytes are zeroed). Similar to XBM.

Actually this online editor seems to display those https://xbm.jazzychad.net/

So it's actually 144 bytes. There are 3 bitmaps:

Pan

Screenshot from 2020-07-29 03-25-48.png (160.81 KiB) Viewed 1882 times

Rotate

Screenshot from 2020-07-29 03-25-21.png (167.26 KiB) Viewed 1882 times

Zoom

Screenshot from 2020-07-29 03-26-20.png (163.78 KiB) Viewed 1882 times

Not sure why the mask is needed. Probably only for transparency. No color is used. Those are black and white cursors used in the 3D view.

[vanuan]

Rescaled the Draft cursor:

https://github.com/FreeCAD/FreeCAD/pull ... 4defc12c28

Before:

Screenshot from 2020-07-29 05-45-27.png (11.42 KiB) Viewed 1872 times

After:

Screenshot from 2020-07-29 05-44-13.png (10.8 KiB) Viewed 1872 times

[vanuan]

Found another one:

Code: Select all

static const char * cursor_ruler[] = {
"32 32 3 1",
" 	c None",
".	c #FFFFFF",
"+	c #FF0000",
"      .                         ",
"      .                         ",
"      .                         ",
"      .                         ",
"      .                         ",
"                                ",
".....   .....                   ",
"                                ",
"      .                         ",
"      .                         ",
"      .        ++               ",
"      .       +  +              ",
"      .      +   ++             ",
"            +   +  +            ",
"           +   +    +           ",
"          +   +     ++          ",
"          +        +  +         ",
"           +           +        ",
"            +         + +       ",
"             +       +   +      ",
"              +           +     ",
"               +         + +    ",
"                +       +   +   ",
"                 +           +  ",
"                  +         + + ",
"                   +       +  ++",
"                    +     +   + ",
"                     +       +  ",
"                      +     +   ",
"                       +   +    ",
"                        + +     ",
"                         +      "};

[mikeprice99]

It doesn't affect plain SVG since inkscape doesn't know anything about author's assumed DPI since the inkscape version is absent in plain SVG

I agree. If an svg file has any data dictionary declarations other than xmlns="http://www.w3.org/2000/svg" then its not plain svg.

My starting point for cleaning up freecad svg files is to run some regex expressions (removing stuff identified by these expressions):

xmlns:.*?\=?".*?"
sodipodi:\w*?\=?".*?"
inkscape:[\w-]*?\=?".*?"
<metadata.*?/metadata>
<sodipodi:namedview.*?/sodipodi:namedview>
id=?"path.*?"
;stroke-opacity:1
;stroke-dashoffset:[0-9.]*
;stroke-dasharray:none

Obviously if the image includes dashes, I won't run the last two lines, but most don't use dashes but oddly include dash styling definitions.