h/t Shin-ichi for reporting seeing warnings about
warning: the comparison will always evaluate as 'true' for the address of 'sizes' will never be NULL
Magic tool ".sizes" was recently turned into an array (per-mode of the
Magic tool), but a few references forgot to account for that.
Corrected like so
e.g., from
if (magics[magic_group][cur_thing].sizes)
to
if (magics[magic_group][cur_thing].sizes[magic_modeint(magics[magic_group][cur_thing].mode)])
If RSVG is < 2.52.x, go back to using rsvg_handle_get_dimensions()
(which is deprecated these days) instead of the newer
rsvg_handle_get_intrinsic_size_in_pixels() that replaced it.
(Shin-ichi reports that function is not available on Rocky Linux 9.)
Note - I also recently replaced rsvg_handle_render_cairo() with
rsvg_handle_render_document(), but Shin-ichi didn't report problems
with that; it's been available since 2.46.
See https://sourceforge.net/p/tuxpaint/bugs/278/
When selecting a label that has a color not found in the built-ins,
we change to the color picker; however, when rendering its button,
it looked wrong and would not fit to the right size (had 48x48
hard-coder in there, still!) Instead, using `render_color_button()`
to just re-render it.
Also, dropping LOW_QUALITY_COLOR_SELECTOR which had been used by
some embedded platforms we don't seem to support any more (Nokia Maemo
and OLPC XO-1).
e.g., for Chinese Traditional, try to use the full font (that
we supply as an optional download), then try the 'subset' font
that we ship with Tux Paint.
Made sure to add our font dir (e.g., /usr/local/share/tuxpaint/fonts/)
to FontConfig's directories before trying to load uifont!
Also, update font names to match what we ship with Tux Paint.
WIP -- Would like to supply some alternatives.
We run shell expansion on configuration arguments,
e.g. `printcommand`, but it would crash if the config
file's input was not quoted, e.g.
printcommand=pstopdf - - > $HOME/print.pdf
Now echo'ing an error to stderr and moving on.
Be sure to quote, e.g.
printcommand="pstopdf - - > $HOME/print.pdf"
The requested font & actual font loaded will be echo'd to STDOUT
when specifying the `uifont` option.
This uses Pango library directly (I was unable to convice SDL2_Pango.h
to actually notice that pango.h was #include'd before it, and expose
its SDLPango_GetPangoFontDescription() function!). This is okay,
since we want to also add a "--uifont list" option (or similar),
that will list all of the available fonts, if a user wishes to
query them. (And similar code will be added to tuxpaint-config to make
the setting available as a pull-down, rather than (or as well as) a
freeform type-in field.)
If not specified, or "default" is specified (e.g., to override
a higher-up config file setting), it will fallback to what we
have #define'd in fonts.h as PANGO_DEFAULT_FONT, "DejaVu Sans".
It appears to fallback to this (or a reasonable fascimile) if
the font specified by the "uifont" option doesn't exist
(e.g., "tuxpaint --uifont=ABCD1234").
For https://sourceforge.net/p/tuxpaint/feature-requests/146/
Final couple of tests to let us avoid creating a template that's
identical to one that already exists. All told, we test the
following (and the first thing that matches causes us to stop
testing that template, and move on to the next, as it appears
to not be identical to the saved image, in its current state)
+ filename prefix (based on saved image's filename)
+ file size
+ image dimensions
+ image contents (via CRC)
Avoid exporting a saved picture to a new template if one already
exists with both the same filename prefix, and now also identical
file sizes (in bytes).
Bugfix - The export function was always dumping chunks that
were the size of the input buffer, which means the final chunk
(which will frequently be smaller) will contain garbage data
beyond the end.
...based on saved files. So far, only looking for identical
template prefix (which is based on the save file's filename).
Next will be to check other fingerprints, in case the saved file
changed after an earlier template was created.
