I am trying to figure out how you calculate the bounding box of a path element. Maybe my topic is an evergreen and I know that there is JavaScript code which does this. Today, I only want documentation.
My own idea was (until this morning) to create the resulting rectangle in a Ruby project. My needs are simple and thus the confrontation with the path commands and the need to “normalize” coordinates if I need to have several <path/> elements covered by a single rectangle, put my project to a halt.
I can read the 'd' attribute, try to follow the commands and interpret the coordinates. For the time being, however, my rectangles are anything but in relation with the sought bounding box.
The pointer to a textual description of the procedure might help, if something like this exists.
If you click the source button to the right. That's from the Inkscape extension api.
You mention Ruby - is this something that you want to do in Inkscape with python or in another language ?
Getting the bounding box in Inkscape is something that lots of extensions do, and drawing a rectangle around it is quite simple.
It simple requires one line of code to get the bounding box my_bbox = my_element.bounding_box()
The snag is that the extension system will only get the path - which is geometric bounding box. To get the visual bounding box - including stroke and filters requires a command call to Inkscape.
Writing an extension has not been my intention, but maybe it will turn out as the simpler alternative.
Background:
My own idea had been to write a script and give it an SVG-file as only argument. What I need is a way to enlarge the pointer-sensitive zone around a linked path. The simplest, graphical, solution to this is a transparent rectangle with pointer-events=all, or just a rectangle as child to the <a/> element, when the <a/> itself gets pointer-events=all. Regardless...
My difficulty is that I do not yet have a good grasp of the path commands (I mean the character values in the 'd' attribute –nothing to do with Inkscape) and thus cannot determine the four corners of the sought rectangle from the coordinates.
Of the API that you suggest, I comprehend lines of code, but do not glimpse in which way it will be useful to me. Sorry, this is just for lack of experience and may be a question of time. But anyway, there should be more – and more talkative – comments. It looks like code for people who know already how to accomplish anything.
If I am interested in understanding Inkscape extensions, I am however in favor of a language-independent description of the procedure.
I feel like I am advancing. Please comment, if some of you know something:
What I need, appears to be kind of a simplistic “path-parser”:
A path command like 'm' or 'M' at the very beginning of a path must trigger the next action and define the initial point for a new path
A 'c', all line-to commands and subsequent 'm' within the same path just signal that the following coordinates can be rendered absolute by adding the value of the initial point's x- and y-values.
As I am anyway working on all paths which are enclosed by a link (<a/>), I can ignore 'z'.
Collecting the absolute (calculated) points I can finally determine minima and maxima, i.e. the four corners of my bounding box.
This should – at least – go into the right direction. If it is, I may write that textual description of the procedure, myself... one day ;)
On the downside, I tend to end my boundlessly praising SVG. You can actually use it as a punishment. Here is a great document (you know it, I did not):
I think I am advancing. Please comment, if some of you know something:
What I need, appears to be kind of a simplistic “path-parser”:
A path command like 'm' or 'M' at the very beginning of a path must trigger the next action and define the initial point for a new path
A 'c', all line-to commands and subsequent 'm' within the same path just signal that the following coordinates can be rendered absolute by adding the value of the initial point's x- and y-values.
As I am anyway working on all paths which are enclosed by one and the same link (<a/>), I can ignore 'z', (edit 19/06/2022) provided, that the next command 'm' does not introduce a new initial point with absolute coordinates. This does, however, not be the case with graphics that are created in Inkscape.
Collecting the absolute (calculated) points I can finally determine minima and maxima, i.e. the four corners of my bounding box.
This should – at least – go into the right direction. If it does, I may write that textual description of the procedure, myself... one day ;)
On the downside, I tend to end my boundlessly praising SVG. You can actually use it as a punishment. Here is a great document (you know it, I did not):
Good morning.
This is related to another thread “Hyperlinks on transparent objects: Is this possible?” and this discussion on gitlab: https://gitlab.com/inkscape/inbox/-/issues/6766#note_906909482
I am trying to figure out how you calculate the bounding box of a path element. Maybe my topic is an evergreen and I know that there is JavaScript code which does this. Today, I only want documentation.
My own idea was (until this morning) to create the resulting rectangle in a Ruby project. My needs are simple and thus the confrontation with the path commands and the need to “normalize” coordinates if I need to have several <path/> elements covered by a single rectangle, put my project to a halt.
I can read the 'd' attribute, try to follow the commands and interpret the coordinates. For the time being, however, my rectangles are anything but in relation with the sought bounding box.
The pointer to a textual description of the procedure might help, if something like this exists.
Thank you in advance.
This might be what you are looking for:
https://inkscape.gitlab.io/extensions/documentation/source/inkex.transforms.html#inkex.transforms.BoundingBox
If you click the source button to the right. That's from the Inkscape extension api.
You mention Ruby - is this something that you want to do in Inkscape with python or in another language ?
Getting the bounding box in Inkscape is something that lots of extensions do, and drawing a rectangle around it is quite simple.
It simple requires one line of code to get the bounding box
my_bbox = my_element.bounding_box()
The snag is that the extension system will only get the path - which is geometric bounding box. To get the visual bounding box - including stroke and filters requires a command call to Inkscape.
Thank you, first of all, for the reference.
Writing an extension has not been my intention, but maybe it will turn out as the simpler alternative.
Background:
My own idea had been to write a script and give it an SVG-file as only argument. What I need is a way to enlarge the pointer-sensitive zone around a linked path. The simplest, graphical, solution to this is a transparent rectangle with pointer-events=all, or just a rectangle as child to the <a/> element, when the <a/> itself gets pointer-events=all. Regardless...
My difficulty is that I do not yet have a good grasp of the path commands (I mean the character values in the 'd' attribute –nothing to do with Inkscape) and thus cannot determine the four corners of the sought rectangle from the coordinates.
Of the API that you suggest, I comprehend lines of code, but do not glimpse in which way it will be useful to me. Sorry, this is just for lack of experience and may be a question of time. But anyway, there should be more – and more talkative – comments. It looks like code for people who know already how to accomplish anything.
If I am interested in understanding Inkscape extensions, I am however in favor of a language-independent description of the procedure.
I feel like I am advancing. Please comment, if some of you know something:
What I need, appears to be kind of a simplistic “path-parser”:
Collecting the absolute (calculated) points I can finally determine minima and maxima, i.e. the four corners of my bounding box.
This should – at least – go into the right direction. If it is, I may write that textual description of the procedure, myself... one day ;)
On the downside, I tend to end my boundlessly praising SVG. You can actually use it as a punishment. Here is a great document (you know it, I did not):
https://www.w3.org/TR/SVG/paths.html#PathDataLinetoCommands
I think I am advancing. Please comment, if some of you know something:
What I need, appears to be kind of a simplistic “path-parser”:
Collecting the absolute (calculated) points I can finally determine minima and maxima, i.e. the four corners of my bounding box.
This should – at least – go into the right direction. If it does, I may write that textual description of the procedure, myself... one day ;)
On the downside, I tend to end my boundlessly praising SVG. You can actually use it as a punishment. Here is a great document (you know it, I did not):
https://www.w3.org/TR/SVG/paths.html#PathDataLinetoCommands
Edits: amendments and Kraut2English