sciurius
commented
7 months ago This is going to take a while... Replying in parts.
- Rounded rectangles
Supported for a while, and the docs have been fixed recently (https://github.com/sciurius/perl-SVGPDF/commit/daaae0d356c18cbec3276bc55169971fd031f99f).
- Apparently I need to call new() for each SVG image, rather than just once, with multiple process()
It should not make a difference. However keep in mind that every call to process adds xobjects to the result. This is correct:
$p = SVGPDF->new;
for ( @svgfiles ) {
$p->process( $_ );
}
for ( $p->xoforms ) {
$gfx->object( $_, ... );
}But this is not:
for ( @svgfiles ) {
$p->process($_);
for ( $p->xoforms ) {
$gfx->object( $_, ... );
}
}
PhilterPaper
As SVGPDF seems to have settled down quite a bit, I'm starting design work on implementing SVG image processing in PDF::Builder, and have some questions about SVGPDF, especially in regards to the font definition callback. I want to be sure I understand your implementation before I go off and do something that will break it!
I want to make use of Builder's FontManager wherever I can, and am not really concerned what happens in PDF::API2 (but obviously I can't request any changes that would break API2). I'm hoping to come up with a nice neat package of a new
image_svg()and being able to pass the resulting$xofarray to the normal$grfx->image()or->object()and handle it appropriately there (new code within to handle a new XObject type or array ref of hashes). Perhaps I can wrap an object around the array, so standard image methods such aswidth()will work. See (13) for more.Apparently I need to call
new()for each SVG image, rather than just once, with multipleprocess()calls. Is that intentional, or a bug? It doesn't make all that much difference if I have to start each image with anew()(it will be hidden withinimage_svg()), but it wasn't documented.If I understand the POD, examples, and tests correctly; when I do
SVGPDF->new()without a font callback, it will use your internal code to try to determine if the requested font is a core font (plus certain aliases, plus some undocumented music fonts... needs to be better documented), and will use that if found. Does it look elsewhere for any fonts (such as along a font path), and are they (a "font-family") assumed to be core fonts, and between the family, weight, and style it comes up with the core font name? Otherwise, use core font Times-Roman size 12 as a fallback. If I only want to treat non-core fonts (as special cases) and fall through to the default in SVGPDF to handle core fonts, is that any problem? I probably will want to handle core fonts in the callback anyway, using FontManager, so that they will be globally cached. The callback seems to be consistent with Builder's FontManager, in that it expects a 'face' (e.g., Times), with separate style (italic on/off) and weight (bold on/off), rather than just a name like TimesBoldItalic. I shouldn't expect to ever see a font-family of "TimesBoldItalic" coming from the SVG, should I?In one of the examples (fontconfig.pl), I see mention of a
fontcache. Is this unique to this example, or is it something global in SVGPDF? Builder's FontManager already caches fonts globally, so once you have created a font from OldeEnglishBlackLetter.otf, there is only one copy around that gets reused as requested. Is the same thing going on only in this example?What is the relationship between
fontsizein the constructor (new) andprocess, andfont-sizepassed in$styleto the callback (presumably from the SVG source)? Is the former just to establish em and ex size, and the latter is to help the user's font callback select a font to open? Doesfont-sizefrom the SVG ever override thefontsizeparameter, or vice-versa? Some clarification would be good. I presume that somewhere, SVG's font-size is being used to set text size. Its availability in the font selection callback might be used how? Maybe someone might choose to use different font files for different ranges of size? If there is no real use for it at this time in the callback, I would just leave it there in case some real use arises.What is the best way to define and use .ttf files, etc.? If I can use my FontManager to select fonts, that would be great, as it includes both non-core fonts, and caching. Is that the intent of the callback? I only have to give a family name, and bold and italic flags, to select a font that it knows about, of any type. If an SVG provides a different font-family name than is defined to Builder's FontManager, it will have to be "translated" on-the-fly (in the callback) to get a face (font-family) that FontManager will recognize (and is defined). The samples I provided include oddities like "1" (not a real font-family; I didn't understand SVG at the time), "MS Shell Dlg 2" and "Microsoft YaHei" (I have no idea what these are; they came used by go.svg), and GNUplot seems to like using "Arial" (a Windows-only core font). I'm thinking of being able to specify that "1" maps to Helvetica, "Microsoft YaHei" maps to Courier, etc. A different set of SVG files might need an entirely different mapping. A "font-map" entry or user-defined flag in
new()that could be passed to the callback would work well; otherwise I need to build new callbacks each time the mapping changes. Don't forget that the 3 additional Windows faces (Georgia, Trebuchet, and Verdana; and GNUplot seems to like Arial, something of a Helvetica clone) need to be substituted on non-Windows systems.SVGPDF also does something with
@font-faces, which could use some clarification in the POD. Is that a font definition in the SVG file, or a mapping to a standard font, or something else? I can't quite tell what it's doing. Also, does SVG allow defining a list of font-family names (like in CSS), and does SVGPDF handle a list properly? This would not be a character-by-character fallback arrangement, but go down the list until a font is found. It might be good to discuss in the POD all the various things infont-familythat SVGPDF can handle.If the user does specify a font selection callback, either as a single entry \&fcsubname (or as an anonymous array
[ \&fcsub1, \&fcsub2, \&fcsub3 ], to try until success?), each callback is passed a fixed set of arguments (including$style). If a suitable font is found and opened successfully, it is returned from the callback. Otherwise, should it returnundef(is a simplereturn;sufficient)? If it runs out of user-supplied callbacks without a successful font load, it acts like no callbacks were defined and uses its internal defaults? I just want to be sure that I understand this, and maybe the documentation could use some fleshing out.Users might supply SVGs with many different oddball font-family entries, and want to change the callback several times in one run, even to the point that a given font-family means different things at different times (dynamically, within a single run). What would be the best way to achieve that? Should they provide an several
sub fc1,sub fc2, etc. and then pick the proper one for thenew(fc => name)? I'm thinking of when the different callbacks might have a lot of code in common, and just a few differences (perhaps they could internally call a common code module). Would that be cleaner than adding an optional entry to the callback, accepting the$stylehashref with a new optional$style->{'font-user'}? Provided by my code, it would be a scalar value that the user could use for any purpose within the callback, such as selecting a different mapping of font-family to real font name (or core). It could even be an arrayref or hashref -- it's up to the user what they want to do with it. If none is provided, thefont-userwould be undef.new()would be a good place to input such a map or other data to the callback (potentially several in a application), rather than having to supply completely different callback routines. If in fact only onenew()is needed for multipleprocess()calls, it could be passed toprocess()instead. I would rather not create an entiresubon-the-fly to do different mappings for different SVG files, rather than defining a fixed one, but is there a better way?I would suggest the heading 'CONSTRUCTOR' be 'CONSTRUCTOR or new()', to minimize confusion among users looking for
new. They may be more used to looking for something callednew, as that's the Perl convention, as opposed to the class name, the C++ convention.In the Font Handler Callback, "don't touch [your]$self". :-) yeah, I saw what you did there!
The POD example of using a font callback in the POD only permits 'sans' (Helvetica) or Times-Roman... you might want to mention what it's doing and the lack of bold or italic, just as a caution to users who use this as a basis for their own callback.
The documentation says that rounded corners on rectangles are not supported, yet your sample seems to use it (
rxandry). Please update if they are now supported.I'm thinking of wrapping an object around the returned $xof array (inside
image_svg()), so it can be treated more like the other image objects. However, it sounds like each element of $xof is more or less an independent image (if there is more than one element) -- any thoughts on how best to "combine" them for an overall width(), height(), bbox(), etc.? Perhaps the bounding boxes can be "plotted" and the lowest and highest of x and y for each gives the overall figures? I have no idea if "real life" multielement cases will overlap fully or partially.