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.
Example
mkdir /tmp/tp
tuxpaint --datadir /tmp/tp
without this fix, choosing "Template" (make a new templat)
from "Open" dialog would result in an error, since
`/tmp/tp/templates` did not exist.
We now `mkdir()` it. This requires, of course, that the
directory specified by `--datadir` _itself_ exists. (We will
not attempt to create anything higher up.)
Places where we attempt to save thumbnails of starters & templates
was trying to `mkdir()` a `.thumbs/` subdirectory in non-existent
`starters/` and `templates/` subdirectories of the "savedir"
location; should be the "datadir" one.
To replicate
mkdir -p /tmp/tp/starters
cp SOMEFILE.png /tmp/tp/starters
tuxpaint --datadir /tmp/tp
then click "New"; observer the warning
Error: Couldn't save thumbnail of saved image!
/tmp/tp/starters/.thumbs/SOMEFILE.png
The error that occurred was:
No such file or directory
When specifying "datadir", Tux Paint's "New" dialog
was able to present templates found in that directory,
but would attempt to load from whatever the user's
"savedir" was, instead.
h/t Giancarlo Orru for reporting the bug.
Was failing to compile on Haiku for Luc (apparently building with
no SVG support), since I started using that function outside of
SVG-related places.
Also, to continue being able to compile on Linux with no SVG support --
* Always use SDL_TRUE & SDL_FALSE, not TRUE & FALSE
* Always link tuxpaint with "-lm"
Finally, verbose version info ("tuxpaint --verbose-version") now states which
SVG build (new RSVG or old Cairo)
I noticed that buttonsize=90 or =91 would end up with UI buttons
images ere one pixel smaller (89x89 or 90x90, respectively) than
expected, hence they layout would end up with one row and one
column of unused pixels between them. Any button content (e.g.
stamp thumbnails) that might render into the full size would end
up leaving garbage pixels behind.
Applying ceil() to the new_x and new_y (but then making sure they do
not exceed the requested max_x and max_y) calculated sizes inside the
thumbnail2() function. (We do not simply use max_x and max_y directly,
because we are usually trying to maintain the original image's aspect
ratio.)
