This was a long standing issue where the image was not printed at the
position as selected in our print preview.
The problem being that we do not take into account the dpi of the print
context we are printing to, but instead always assumed 72.
This is the fix that was suggested by Massimo.
As mentioned by Massimo in issue #6618, part of the problem there is an
integer overflow when using large size images when computing the offset
in pixels.
Let's fix our part of the problem by casting to guint64.
Besides that, also use casts to correctly compute progress for very
large images.
The gimp_drawable_type() is an issue though as gimp_drawable_get_type()
is already defined as a common GObject API.
Though I'm actually wondering if GimpImageType is well called. Rather
than Type, shouldn't we go with ColorModel?
sed -i 's/\<gimp_drawable_bpp\>/gimp_drawable_get_bpp/g' "$@"
sed -i 's/\<gimp_drawable_width\>/gimp_drawable_get_width/g' "$@"
sed -i 's/\<gimp_drawable_height\>/gimp_drawable_get_height/g' "$@"
sed -i 's/\<gimp_drawable_offsets\>/gimp_drawable_get_offsets/g' "$@"
Similarly to the previous commit, it is not only about using the new
API. I also make sure we do not assume that parasite data is
nul-terminated. In many places, we were just assuming so because these
were supposed to be parasite our code set. Yet these are data input
contained in files which can be wrong for any reason (corrupted file,
bugs, other scripts/plug-ins editing these parasites…). So instead of
assuming string parasites are always correctly formatted, I make sure
they are nul-terminated by passing them through g_strndup() when
necessary.
This gives a big cleanup in the meson.build files of the plug-ins.
It's also quite a bit more maintainable, since anything that changes in
libgimp's dependencies, linkage, ... doesn't have to be copy-pasted into
each plug-in.
I am going to forbid plug-ins from being installed directly in the root
of the plug-ins/ directory. They will have to be installed in a
subdirectory named the same as the entry point binary.
This may seem useless for our core plug-ins which are nearly all
self-contained in single binaries, but this is actually a necessary
restriction to eliminate totally the DLL hell issue on Windows. Moving
core plug-ins in subfolders is only a necessary consequence for it.
Try to sort all GIMP_ICON_* defines into FDO categories like in
https://specifications.freedesktop.org/icon-naming-spec/latest/ar01s04.html
Add defines for all icons we override, rename some icons to their FDO
standard names, and mark the ones we duplicate with a comment so we
don't forget to rename those to standard names in 3.0.
Also take into account the case when the minimum possible print
resolution is higher than the expected image resolution. We don't want
to remember the print resolution if it is this lower value either.
See commit 7335dc8.
... for second printing.
Do not save in parasite the resolution used in the print plug-in when
it is the image intended resolution. This allows to take into account
changes of print resolution in successive printing. Only save it when
different since one may have reasons and we should not interfere.
... in the print plug-in.
The resolution set during printing may be different from the print size,
for various reason (home printing vs. printshop for instance). The print
plug-in's resolution is saved and reused from a non-persistent parasite,
thus masking actual intended print resolution. Adding this button allows
to reset this temporary value to the intended resolution at any time.
and keep GIMP_ICON_TYPE_STOCK_ID as a deprecated alias. Change all
plug-ins accordingly and increase the pluginrc file version number so
it gets regenerated with "icon-name" instead of "stock-id".
Jacob Boerema