procyberian/gimp
2
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/gimp.git synced 2025-07-04 01:43:24 +00:00
Code Issues 1 Projects 1 Releases Packages Wiki Activity Actions
gimp/libgimp/gimpvectorloadprocedure.h

179 lines
9 KiB
C
Raw Normal View History

app, libgimp, pdb: new GimpVectorLoadProcedure class. It's still basic but will help to share code for support of various vector-able formats, such as the logic for dimensioning them, but also the generated GUI. Not only this, but we are paving the way for the link layers (though it'll be after GIMP 3, we want plug-in procedures' API to stay stable) by giving a way for a plug-in procedure to advertize a vector format support. This way, the core will know when a source file is vector and can be directly reloaded at any target size (right now, in my MR for link layers, the list of "vector" formats is hardcoded, which is not reliable).
2024-04-22 23:11:37 +02:00
/* GIMP - The GNU Image Manipulation Program
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
*
* gimpvectorloadprocedure.h
* Copyright (C) 2024 Jehan
*
* This library is free software: you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 3 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see
* <https://www.gnu.org/licenses/>.
*/
#ifndef __GIMP_VECTOR_LOAD_PROCEDURE_H__
#define __GIMP_VECTOR_LOAD_PROCEDURE_H__
#include <libgimp/gimpfileprocedure.h>
G_BEGIN_DECLS
/* For information look into the C source or the html documentation */
app, libgimp, plug-ins: improve GimpVectorLoadProcedure workflow. I'm moving the logic of choosing a correct default for width/height by adding an "extract dimensions" callback in the procedure. The logic is that every vector format out there should likely have metadata either for pixel dimensions or physical dimensions, or at the very least for no-unit dimensions (ratio only). Vector load procedures will have to implement only the extraction of such data in a callback called by GIMP but not how to act upon them, so that we have a common logic for all vector images. I am implementing this callback first in the SVG plug-in, moving all the code to extract dimensions (and improving it) in this callback. Also I am deleting "file-svg-load-thumb" procedure. I could simply reimplement it using the same code, but it looks to me like this is very useless for vector formats to have a specific thumbnail procedure (unless it were to use very specific metadata for faster result). This is vector data, just ask it directly at the proper bounding box size.
2024-04-26 01:07:59 +02:00
typedef struct _GimpVectorLoadData
{
gdouble width;
GimpUnit width_unit;
gboolean exact_width;
gdouble height;
GimpUnit height_unit;
gboolean exact_height;
gboolean correct_ratio;
gdouble pixel_density;
GimpUnit density_unit;
gboolean exact_density;
} GimpVectorLoadData;
app, libgimp, pdb: new GimpVectorLoadProcedure class. It's still basic but will help to share code for support of various vector-able formats, such as the logic for dimensioning them, but also the generated GUI. Not only this, but we are paving the way for the link layers (though it'll be after GIMP 3, we want plug-in procedures' API to stay stable) by giving a way for a plug-in procedure to advertize a vector format support. This way, the core will know when a source file is vector and can be directly reloaded at any target size (right now, in my MR for link layers, the list of "vector" formats is hardcoded, which is not reliable).
2024-04-22 23:11:37 +02:00
/**
* GimpRunVectorLoadFunc:
* @procedure: the [class@Gimp.Procedure] that runs.
* @run_mode: the [enum@RunMode].
libgimp: fix libgimp introspection. - Fix a few broken references and an inconsistent argument name. - Add the new headers in the introspectable header list. - Add a few missing class descriptions for GimpProcedure and subclasses.
2024-04-24 16:02:08 +02:00
* @file: the [iface@Gio.File] to load from.
app, libgimp, pdb: new GimpVectorLoadProcedure class. It's still basic but will help to share code for support of various vector-able formats, such as the logic for dimensioning them, but also the generated GUI. Not only this, but we are paving the way for the link layers (though it'll be after GIMP 3, we want plug-in procedures' API to stay stable) by giving a way for a plug-in procedure to advertize a vector format support. This way, the core will know when a source file is vector and can be directly reloaded at any target size (right now, in my MR for link layers, the list of "vector" formats is hardcoded, which is not reliable).
2024-04-22 23:11:37 +02:00
* @width: the desired width in pixel for the created image.
* @height: the desired height in pixel for the created image.
app, libgimp, plug-ins: improve GimpVectorLoadProcedure workflow. I'm moving the logic of choosing a correct default for width/height by adding an "extract dimensions" callback in the procedure. The logic is that every vector format out there should likely have metadata either for pixel dimensions or physical dimensions, or at the very least for no-unit dimensions (ratio only). Vector load procedures will have to implement only the extraction of such data in a callback called by GIMP but not how to act upon them, so that we have a common logic for all vector images. I am implementing this callback first in the SVG plug-in, moving all the code to extract dimensions (and improving it) in this callback. Also I am deleting "file-svg-load-thumb" procedure. I could simply reimplement it using the same code, but it looks to me like this is very useless for vector formats to have a specific thumbnail procedure (unless it were to use very specific metadata for faster result). This is vector data, just ask it directly at the proper bounding box size.
2024-04-26 01:07:59 +02:00
* @extracted_data: dimensions returned by [callback@ExtractVectorFunc].
app, libgimp, pdb: new GimpVectorLoadProcedure class. It's still basic but will help to share code for support of various vector-able formats, such as the logic for dimensioning them, but also the generated GUI. Not only this, but we are paving the way for the link layers (though it'll be after GIMP 3, we want plug-in procedures' API to stay stable) by giving a way for a plug-in procedure to advertize a vector format support. This way, the core will know when a source file is vector and can be directly reloaded at any target size (right now, in my MR for link layers, the list of "vector" formats is hardcoded, which is not reliable).
2024-04-22 23:11:37 +02:00
* @metadata: the [class@Gimp.Metadata] which will be added to the new image.
* @flags: (inout): flags to filter which metadata will be added..
* @config: the @procedure's remaining arguments.
app, libgimp, plug-ins: improve GimpVectorLoadProcedure workflow. I'm moving the logic of choosing a correct default for width/height by adding an "extract dimensions" callback in the procedure. The logic is that every vector format out there should likely have metadata either for pixel dimensions or physical dimensions, or at the very least for no-unit dimensions (ratio only). Vector load procedures will have to implement only the extraction of such data in a callback called by GIMP but not how to act upon them, so that we have a common logic for all vector images. I am implementing this callback first in the SVG plug-in, moving all the code to extract dimensions (and improving it) in this callback. Also I am deleting "file-svg-load-thumb" procedure. I could simply reimplement it using the same code, but it looks to me like this is very useless for vector formats to have a specific thumbnail procedure (unless it were to use very specific metadata for faster result). This is vector data, just ask it directly at the proper bounding box size.
2024-04-26 01:07:59 +02:00
* @data_from_extract: (closure): @data_for_run returned by [callback@ExtractVectorFunc].
* @run_data: (closure): @run_data given in gimp_vector_load_procedure_new().
app, libgimp, pdb: new GimpVectorLoadProcedure class. It's still basic but will help to share code for support of various vector-able formats, such as the logic for dimensioning them, but also the generated GUI. Not only this, but we are paving the way for the link layers (though it'll be after GIMP 3, we want plug-in procedures' API to stay stable) by giving a way for a plug-in procedure to advertize a vector format support. This way, the core will know when a source file is vector and can be directly reloaded at any target size (right now, in my MR for link layers, the list of "vector" formats is hardcoded, which is not reliable).
2024-04-22 23:11:37 +02:00
*
* The load function is run during the lifetime of the GIMP session, each time a
* plug-in load procedure is called.
*
* You are expected to read @file and create a [class@Gimp.Image] out of its
* data. This image will be the first return value.
* @metadata will be filled from metadata from @file if our infrastructure
* supports this format. You may tweak this object, for instance adding metadata
* specific to the format. You can also edit @flags if you need to filter out
* some specific common fields. For instance, it is customary to remove a
libgimp: fix libgimp introspection. - Fix a few broken references and an inconsistent argument name. - Add the new headers in the introspectable header list. - Add a few missing class descriptions for GimpProcedure and subclasses.
2024-04-24 16:02:08 +02:00
* colorspace field with [flags@MetadataLoadFlags] when a profile was added.
app, libgimp, pdb: new GimpVectorLoadProcedure class. It's still basic but will help to share code for support of various vector-able formats, such as the logic for dimensioning them, but also the generated GUI. Not only this, but we are paving the way for the link layers (though it'll be after GIMP 3, we want plug-in procedures' API to stay stable) by giving a way for a plug-in procedure to advertize a vector format support. This way, the core will know when a source file is vector and can be directly reloaded at any target size (right now, in my MR for link layers, the list of "vector" formats is hardcoded, which is not reliable).
2024-04-22 23:11:37 +02:00
*
* Regarding returned image dimensions:
*
* 1. If @width or @height is 0 or negative, the actual value will be computed
* so that ratio is preserved. If @prefer_native_dimension is %FALSE, at
* least one of the 2 dimensions should be strictly positive.
* 2. If @preserve_ratio is %TRUE, then @width and @height are considered as a
* max size in their respective dimension. I.e. that the resulting image will
* be at most @widthx@height while preserving original ratio. @preserve_ratio
* is implied when any of the dimension is 0 or negative.
* 3. If @prefer_native_dimension is %TRUE, and if the image has some kind of
* native size (if the format has such metadata or it can be computed), it
* will be used rather than @widthx@height. Note that if both dimensions are
* 0 or negative, even if @prefer_native_dimension is TRUE yet the procedure
* cannot determine native dimensions, then maybe a dialog could be popped
* up (if implemented), unless the @run_mode is [enum@RunMode.NONINTERACTIVE].
*
* Returns: (transfer full): the @procedure's return values.
*
* Since: 3.0
**/
typedef GimpValueArray * (* GimpRunVectorLoadFunc) (GimpProcedure *procedure,
GimpRunMode run_mode,
GFile *file,
gint width,
gint height,
app, libgimp, plug-ins: improve GimpVectorLoadProcedure workflow. I'm moving the logic of choosing a correct default for width/height by adding an "extract dimensions" callback in the procedure. The logic is that every vector format out there should likely have metadata either for pixel dimensions or physical dimensions, or at the very least for no-unit dimensions (ratio only). Vector load procedures will have to implement only the extraction of such data in a callback called by GIMP but not how to act upon them, so that we have a common logic for all vector images. I am implementing this callback first in the SVG plug-in, moving all the code to extract dimensions (and improving it) in this callback. Also I am deleting "file-svg-load-thumb" procedure. I could simply reimplement it using the same code, but it looks to me like this is very useless for vector formats to have a specific thumbnail procedure (unless it were to use very specific metadata for faster result). This is vector data, just ask it directly at the proper bounding box size.
2024-04-26 01:07:59 +02:00
GimpVectorLoadData extracted_data,
app, libgimp, pdb: new GimpVectorLoadProcedure class. It's still basic but will help to share code for support of various vector-able formats, such as the logic for dimensioning them, but also the generated GUI. Not only this, but we are paving the way for the link layers (though it'll be after GIMP 3, we want plug-in procedures' API to stay stable) by giving a way for a plug-in procedure to advertize a vector format support. This way, the core will know when a source file is vector and can be directly reloaded at any target size (right now, in my MR for link layers, the list of "vector" formats is hardcoded, which is not reliable).
2024-04-22 23:11:37 +02:00
GimpMetadata *metadata,
GimpMetadataLoadFlags *flags,
GimpProcedureConfig *config,
app, libgimp, plug-ins: improve GimpVectorLoadProcedure workflow. I'm moving the logic of choosing a correct default for width/height by adding an "extract dimensions" callback in the procedure. The logic is that every vector format out there should likely have metadata either for pixel dimensions or physical dimensions, or at the very least for no-unit dimensions (ratio only). Vector load procedures will have to implement only the extraction of such data in a callback called by GIMP but not how to act upon them, so that we have a common logic for all vector images. I am implementing this callback first in the SVG plug-in, moving all the code to extract dimensions (and improving it) in this callback. Also I am deleting "file-svg-load-thumb" procedure. I could simply reimplement it using the same code, but it looks to me like this is very useless for vector formats to have a specific thumbnail procedure (unless it were to use very specific metadata for faster result). This is vector data, just ask it directly at the proper bounding box size.
2024-04-26 01:07:59 +02:00
gpointer data_from_extract,
app, libgimp, pdb: new GimpVectorLoadProcedure class. It's still basic but will help to share code for support of various vector-able formats, such as the logic for dimensioning them, but also the generated GUI. Not only this, but we are paving the way for the link layers (though it'll be after GIMP 3, we want plug-in procedures' API to stay stable) by giving a way for a plug-in procedure to advertize a vector format support. This way, the core will know when a source file is vector and can be directly reloaded at any target size (right now, in my MR for link layers, the list of "vector" formats is hardcoded, which is not reliable).
2024-04-22 23:11:37 +02:00
gpointer run_data);
app, libgimp, plug-ins: improve GimpVectorLoadProcedure workflow. I'm moving the logic of choosing a correct default for width/height by adding an "extract dimensions" callback in the procedure. The logic is that every vector format out there should likely have metadata either for pixel dimensions or physical dimensions, or at the very least for no-unit dimensions (ratio only). Vector load procedures will have to implement only the extraction of such data in a callback called by GIMP but not how to act upon them, so that we have a common logic for all vector images. I am implementing this callback first in the SVG plug-in, moving all the code to extract dimensions (and improving it) in this callback. Also I am deleting "file-svg-load-thumb" procedure. I could simply reimplement it using the same code, but it looks to me like this is very useless for vector formats to have a specific thumbnail procedure (unless it were to use very specific metadata for faster result). This is vector data, just ask it directly at the proper bounding box size.
2024-04-26 01:07:59 +02:00
/**
* GimpExtractVectorFunc:
* @procedure: the [class@Gimp.Procedure].
* @run_mode: the [enum@RunMode].
* @metadata: the [class@Gimp.Metadata] which will be added to the new image.
* @config: the @procedure's remaining arguments.
* @file: the [iface@Gio.File] to load from.
* @extracted_data: (out): dimensions and pixel density extracted from @file.
* @data_for_run: (out) (nullable): will be passed as @data_from_extract in [callback@RunVectorLoadFunc].
* @data_for_run_destroy: (out) (nullable) (destroy data_for_run): the free function for @data_for_run.
* @extract_data: (closure): the @extract_data given in [ctor@VectorLoadProcedure.new].
* @error: (out): error to be filled when @file cannot be loaded.
*
* Loading a vector image happens in 2 steps:
*
* 1. this function is first run to determine which size should be actually requested.
* 2. [callback@RunVectorLoadFunc] is called with the suggested @width and @height.
*
* This function is run during the lifetime of the GIMP session, as the first
* step above. It should extract the maximum of information from the source
* document to help GIMP take appropriate decisions for default values and also
* for displaying relevant information in the load dialog (if necessary).
*
* The best case scenario is to be able to extract proper dimensions (@width and
* @height) with valid units supported by GIMP. If not possible, returning
* already processed dimensions then setting @exact_width and @exact_height to
* %FALSE in @extracted_data is also an option. If all you can get are no-unit
* dimensions, set them with %GIMP_UNIT_PIXEL and %correct_ratio to %TRUE to at
* least give a valid ratio as a default.
*
* If there is no way to extract any valid default dimensions, not even a ratio,
* then return %FALSE but leave %error as %NULL. [callback@RunVectorLoadFunc]
* will still be called but default values might be bogus.
* If the return value is %FALSE and %error is set, it means that the file is
* invalid and cannot even be loaded. Thus [callback@RunVectorLoadFunc] won't be
* run and %error
*
* Returns: %TRUE if any information could be extracted from @file.
*
* Since: 3.0
**/
typedef gboolean (* GimpExtractVectorFunc) (GimpProcedure *procedure,
GimpRunMode run_mode,
GFile *file,
GimpMetadata *metadata,
GimpProcedureConfig *config,
GimpVectorLoadData *extracted_data,
gpointer *data_for_run,
GDestroyNotify *data_for_run_destroy,
gpointer extract_data,
GError **error);
app, libgimp, pdb: new GimpVectorLoadProcedure class. It's still basic but will help to share code for support of various vector-able formats, such as the logic for dimensioning them, but also the generated GUI. Not only this, but we are paving the way for the link layers (though it'll be after GIMP 3, we want plug-in procedures' API to stay stable) by giving a way for a plug-in procedure to advertize a vector format support. This way, the core will know when a source file is vector and can be directly reloaded at any target size (right now, in my MR for link layers, the list of "vector" formats is hardcoded, which is not reliable).
2024-04-22 23:11:37 +02:00
#define GIMP_TYPE_VECTOR_LOAD_PROCEDURE (gimp_vector_load_procedure_get_type ())
G_DECLARE_FINAL_TYPE (GimpVectorLoadProcedure, gimp_vector_load_procedure, GIMP, VECTOR_LOAD_PROCEDURE, GimpLoadProcedure)
typedef struct _GimpVectorLoadProcedure GimpVectorLoadProcedure;
app, libgimp, plug-ins: improve GimpVectorLoadProcedure workflow. I'm moving the logic of choosing a correct default for width/height by adding an "extract dimensions" callback in the procedure. The logic is that every vector format out there should likely have metadata either for pixel dimensions or physical dimensions, or at the very least for no-unit dimensions (ratio only). Vector load procedures will have to implement only the extraction of such data in a callback called by GIMP but not how to act upon them, so that we have a common logic for all vector images. I am implementing this callback first in the SVG plug-in, moving all the code to extract dimensions (and improving it) in this callback. Also I am deleting "file-svg-load-thumb" procedure. I could simply reimplement it using the same code, but it looks to me like this is very useless for vector formats to have a specific thumbnail procedure (unless it were to use very specific metadata for faster result). This is vector data, just ask it directly at the proper bounding box size.
2024-04-26 01:07:59 +02:00
GimpProcedure * gimp_vector_load_procedure_new (GimpPlugIn *plug_in,
const gchar *name,
GimpPDBProcType proc_type,
GimpExtractVectorFunc extract_func,
gpointer extract_data,
GDestroyNotify extract_data_destroy,
GimpRunVectorLoadFunc run_func,
gpointer run_data,
GDestroyNotify run_data_destroy);
app, libgimp, pdb: new GimpVectorLoadProcedure class. It's still basic but will help to share code for support of various vector-able formats, such as the logic for dimensioning them, but also the generated GUI. Not only this, but we are paving the way for the link layers (though it'll be after GIMP 3, we want plug-in procedures' API to stay stable) by giving a way for a plug-in procedure to advertize a vector format support. This way, the core will know when a source file is vector and can be directly reloaded at any target size (right now, in my MR for link layers, the list of "vector" formats is hardcoded, which is not reliable).
2024-04-22 23:11:37 +02:00
G_END_DECLS
#endif /* __GIMP_VECTOR_LOAD_PROCEDURE_H__ */
Reference in a new issue Copy permalink