Commit dc069e424a removed the
assumption that 1-bpp PCX files are B&W, in favor of using the
provided palette, which is (supposedly?) the correct behavior.
However, there are evidently B&W files that do not specify a
palette, resulting in an all-black image (i.e., a 2-color indexed
image, whose both palette entries are black). Since other
software, including older versions of GIMP, load such files
"correctly", let's fix this by falling back to a B&W palette when
the provded palette is uniform.
(cherry picked from commit 11defa4271)
but only the actual saving code, not the export magic and dialog.
Add new internal procedure file-pat-save-internal which is not
registered as a file procedure and always works non-interactively on
the passed arguments and only saves the passed drawable. Use the new
internal procedure from the file-pat-save code and remove all file
writing code from the plug-in.
This way all pattern file writing code duplication is killed, while
the whole export mechanism is completely unchanged.
(cherry picked from commit b29ecfb5da)
We currently have brush and pattern I/O code in both the core and
plug-ins. This commit starts removing plug-in code in favor of having
one copy of the code in the core, much like XCF loading and saving is
implemented.
Add app/file-data/ module with file procedure registering code, for
now just with an implementation of file-gbr-load.
Remove the file-gbr-load code from the file-gbr plug-in.
(cherry picked from commit a4e77e57f6)
I am unsure of the problem, but it is fixed by using
poppler_document_new_from_gfile() instead of giving the contents of a
GMappedFile to poppler_document_new_from_data().
Using GFile is anyway usually prefered so I don't dig up more and just
make this change.
(cherry picked from commit a89e503054)
As correctly spotted by Royce Pipkins, the buffer for the drawable's
pixel lines was too small.
Also fix the plug-in to hardcode "R'G'B'[A] u8" so it won't misbehave
on high bit-depth images, and make it work on all sorts of drawables,
not only "RGB*" (it will still always export RGB images).
(cherry picked from commit 74c9d835e8)
As I did on app/, finalizing an output stream also implicitly flushes
and closes it. Hence if an export ended with an error, we'd end up with
incomplete data file (possibly overwriting a previously exported image).
Only 2 plug-ins I haven't fixed yet are file-tiff-io and file-gif-save.
The later one don't even clean up its memory (which somehow is good here
as at least the output stream is never finalized hence sane files are
not overwritten in case of errors). As for the former (TIFF plug-in), it
doesn't even seem to have any error control AFAICS, apart from printing
error messages on standard error output.
(cherry picked from commit 66ec467217)
Add flag GIMP_METADATA_SAVE_COLOR_PROFILE to GimpMetadataSaveFlags and
initialize it from gimp_export_color_profile() in
gimp_image_metadata_save_prepare().
Adapt all plug-ins to use the bit from the suggested export flags and
pass the actually used value back to
gimp_image_metadata_save_finish().
This changes no behavior at all but creates hooks on the libgimp side
that are called with the context of an image before and after the
actual export, which might become useful later. Also, consistency
is good even though the color profile is not strictly "metadata".
(cherry picked from commit c667fdc5c0)
Nothing said what was going to be the order of the page, except by
testing. Now there will be an explicit text, which will be automatically
updated when checking the "reverse order" box.
(cherry picked from commit afe1de950f)
... only shows the color (and nothing else) when "Convert bitmaps to
vector graphics where possible" was set.
This is because gimp_drawable_histogram() only checks selected pixels.
So let's make sure we work on a duplicate of the image so that we can
safely remove the selection before processing the export.
Add line data padding when necessary.
Additionally I realize we should convert to little-endian after checking
the bytesperline oddness (this bug was most likely unnoticed until now
as most desktop proc are little endian now anyway).
(cherry picked from commit 5d319b77bf)
Add missing fclose invocations and fix copy-paste issue.
This issues has been discovered by coverity scan proceeded by Red Hat.
Fixed some mistakes in the patch and added more fclose() (Mitch)
After Dirk Farin had another look in the specs, it turns out that "mif1"
is actually allowed as major brand for HEIF. Also adding "msf1" which is
the equivalent for image sequences.
(cherry picked from commit 64b00b5c7f)
Just looking for "ftyp" would also match other ISOBMFF files (.mov or
.mp4 files for instance). These are the possible 4-byte "brand" code
which can follow "ftyp", as listed by Dirk Farin from libheif.
I add the "mif1" brand, as I encountered some files using this magic
(even though this should normally not be valid apparently, yet the file
loaded fine in GIMP).
This is not perfect as the standard allows potentially very big box
headers, in which case 8 bytes (the "largesize" slot) may be inserted
between "ftyp" and the brand, as I understand it. But this is actually
unlikely enough to probably never happen (the compatible brands list
would have to be huuuge, as it looks like this is the only extendable
part in a ftyp box). So let's assume this just never happens.
See also: https://github.com/strukturag/libheif/issues/83
(cherry picked from commit 4ad3993eca)
Adding a magic number for HEIC/HEIF, which would allow to discard
obvious non-HEIC images even with the wrong extension.
Note: it looks like this magic number would also match more generically
other ISO base media file format (ISOBMFF) formats, like .mov or .mp4
files. I am enquiring for better magic but for now, this is better than
nothing.
(cherry picked from commit d738d2f645)
When cross-compiling, I got various linking errors for printf() calls:
> undefined reference to `libintl_printf'
I am unsure why, since this is not recent code, and it used to build
fine with mingw64 compilers (last I cross-built, which is many months
ago). Anyway g_printf() works fine, all necessary libs are already
linked, and it is supposed to be a synonym. So let's just go the easy
way and use g_printf() only.
Introduce GIMP_PATTERN_MAX_SIZE (10000) and GIMP_PATTERN_MAX_NAME (256)
and validate pattern dimensions and pattern name length against them.
Add GIMP_BRUSH_MAX_NAME and validate that too.
Also make sure that the names are properly terminated, and some
cleanup.
(cherry picked from commit 9b56ca8c1d)
When ENABLE_RELOCATABLE_RESOURCES is set, override libwmf fontdir. This
is actually an alternate version of MR !9 by Alex Samorukov assuming a
bundled GIMP on a single prefix rather than depending on an environment
variable.
This especially makes the relocatable feature more discoverable (rather
than some random environment variable for which you'd need to read the
code to discover it then make some wrapper script for GIMP).
(cherry picked from commit 4ff856f68d)
