After testing a bit more, I realized that the thread was constantly re-rendering
the thumbnails, even though I didn't touch the "white-background"
button/argument.
This was not just a completely invisible problem, it actually affected the page
selection (it was very hard to select pages by clicking on them, it was randomly
working, and more often not selecting anything). This is how I realized there
was a problem.
The reason was simply that I was never actually calling g_cond_wait() because of
a first_loop flag I forgot to set.
Note that docs of g_cond_wait() explains that it is possible that "spurious
wakeup" happen. At first I thought I had this issue, which is why this commit
also adds a boolean flag to check after a wakeup, to make sure that I was in the
"condition met" case and not the "spurious wakeup" one.
Even though I realized afterwards the real reason was much more stupid, I still
left this additional check.
Fortunately this issue doesn't seem to affect the 2.10 code. Or to be more
accurate: the continuous render very likely happens there too, yet it doesn't
break page selection interaction with GTK+2 as far as I can see.
Port commit 41f40f530a from gimp-2-10 branch to the main branch:
While at first, the idea of always loading PDF with transparency seemed good
(commit 7aff7e9c70), I realized that a lot of administrative PDF (generated with
text and vector graphics, rather than scans or alike containing raster) actually
have transparency. So now all these documents load with transparent background.
Clearly all the office software are assuming that PDF readers will fill the
background with white.
So add a checkbox to decide whether or not to fill the image with white. I don't
update the PDB procedure. I'll just do this on the main dev branch (while also
updating a bit the code to newer API).
Fortunately I regularly open such PDF documents with GIMP and could witness this
no-transparency expectation before we released GIMP 2.10.34! 😅
As side changes, I also:
* ported file-pdf-load to work with GimpProcedureConfig arguments instead of
GimpValueArray;
* ported the dialog to GimpProcedureDialog and generating as much of it as
possible (except for the page selector/preview, and resolution entries);
* renamed the "pdf-password" argument to "password";
* added the "target", "antialias" and "white-background" procedure arguments.
A few issues which would deserve to be looked at more closely in the future:
* adding "width" and "height" arguments and decide how to handle "resolution";
this will likely be better handled with a new GimpVectorLoadProcedure subclass
to support vector formats in particular;
* shouldn't page selection be handled in a better way? Probably this could be
handled by adding a generic logic in GimpLoadProcedure (as multi-page support
is a common feature across image formats);
* GimpInt32Array arguments ("pages") can't be stored anyway right now.
* the "target" arg should be an enum.
This is a placeholder which is not meant to appear in the menu. Our new system
uses placeholders internally, but plug-ins cannot make use of these.
Not sure anyway if this is so useful in the cases of plug-ins. At least, I don't
feel it is for these particular use cases.
I noticed after porting the last few plug-ins that GimpPreview went
to black when you unchecked the auto-preview option.
These widgets must be added directly to the dialogue rather than via the
new API in order for the unfiltered image drawable to be loaded
properly. They will eventually be removed in favor of on-canvas preview,
but let's get them working correctly for now.
Two of our scripts have a spinbutton step size the same as the page size.
Since page size should be larger than the step size, this causes a
CRITICAL in LibGimpWidgets:
gimp_label_spin_set_increments: assertion 'step < page' failed
We fix this by setting a page size larger than step size in
coffee.scm and tileblur.scm.
If a 1 bit PCX image is opened interactively, a dialogue will let
users choose to either use the built-in palette, or force the colors to
be black/white only. Otherwise, the user can choose this via a script
parameter.
Users have noted that legacy layer modes have better compatibility
when exporting PSDs and reopening them in Photoshop.
This patch adds a notice with that information to the PSD export GUI.
- Use a pre-defined MAXDATABLOCKSIZE for all the buffers filled with
GetDataBlock that is known to be large enough.
- When reading comments ensure that it always ends with a NULL.
- Ensure that the right/bottom frame dimensions are also within range.
Inspired by issue #9195 I went over how we handled error messages when
loading GIF images.
- I replaced some cases with g_set_error and added an error parameter to
ReadImage.
- Introduced function read_error that uses g_set_error when image == NULL,
or else g_message.
- Enabled translations for the messages.
- Synchronized the error messages used to reduce the amount of work for
translators.
- Changed the error code returned internally in a few places, to be better
able to distinguish between encountering and end_code (-2) and possible
corruption errors (-1).
- Moved allocating dest down to not need freeing it in case of error.
- Allow to show partial results in case of errors.
The IART and INAM metadata fields were stored in gchar arrays,
which have a limit of G_MAXSHORT indexes.
However, you can have strings larger than that in the format.
To prevent overflows, they were changed to gchar*. f_read ()'s result
is also checked, and an error is set if it returns 0.
The frame count variable is also now reset per icon block to prevent
overflow as well.
This ports the main dialogue to use GimpProcedureConfig.
It also adds the GUI-only options to the procedure itself, so that you
can call them via scripts.
Additionally, the layer warning was fixed and
mnemonics were added to the
property titles.
@Wormnest notified me of issues with CMYK profiles overwriting existing
ones, and potentially access a dereferenced profile.
This patch adds an additional condition check, and clears out the
profile in addition to dereferencing it.
Jehan