View on
MetaCPAN is shutting down
For details read Perl NOC. After June 25th this page will redirect to
Lutz Gehlen > SVG-Rasterize-0.003008 > SVG::Rasterize::Specification



Annotate this POD


New  2
Open  1
View/Report Bugs
Module Version: 0.003007   Source  


SVG::Rasterize::Specification - data structures derived from DTD


Version 0.003007


This file was automatically generated using the SVG DTD available under

The data structures are used mainly by SVG::Rasterize::State for validation and processing of the SVG input tree.



The datatypes are defined by entities in the DTD, but they all expand to 'CDATA'. SVG::Rasterize makes use of this finer granularity of the DTD by overriding this entity expansion.


The SVG elements are divided into classes in the DTD. This is used to split the generated data structures into a set of modules. Thus it is possible to load only those parts of the specification that are needed for a specific SVG document.


Some manual additions are made to the automatically generated data structures. Currently, this is only the xmlns:svg attribute which is set by default by the SVG module. I am not sure if this is against the SVG specification or not. The DTD allows to enable prefixes which then might allow to set this attribute. Therefore, I decided to allow it as well.


As mentioned above, the data structures are distributed over several modules in order to improve loading time of SVG::Rasterize. The price of this is that the data structures must not be accessed directly. Instead, s set of subroutines handle the access and load the required modules when necessary.

Subroutines offered for Import

Because of the length of the class name SVG::Rasterize::Specification I have decided to offer the subroutines for import. However, to minimize the danger of name clashes and to clearly label them for any reader of the code, the subroutine names are prefixed with 'spec'.

The subroutines throw as few exceptions as possible. The only one is if a necessary specification module cannot be loaded. Besides, the subroutines return undef on bad input. I see this behaviour vindicated by the fact that these subroutines are deeply internal and in the normal flow of the rasterization process the validity of the parameters has already been checked upstream.

All subroutines return undef if one of the parameters is undef or a reference. For the additional behaviour, see below.



Returns 1 if there is an SVG element of name $element_name, 0 otherwise.


  spec_has_child($parent_element_name, $child_element_name)

Returns undef if there is no SVG element of name $parent_element_name. Otherwise, returns 1 if the element is allowed to have child elements of name $child_element_name, 0 if it is not allowed.



Returns undef if there is no SVG element of name $element_name. Otherwise, returns 1 if the element is allowed to contain parsed character data (other than white space), 0 if it is not allowed.


  spec_has_attribute($element_name, $attribute_name)

Returns undef if there is no SVG element of name $element_name. Otherwise, returns 1 if the element is allowed to have an attribute of name $attribute_name, 0 if it is not allowed.



Returns undef if there is no SVG element of name $element_name. Otherwise, returns a HASH reference that can be passed to Params::Validate::validate or Params::Validate::validate_with for validation of an attribute hash.



Returns undef if there is no SVG element of name $element_name. Otherwise, returns a HASH reference with further information about the element's attributes. If an attribute is a color then the color entry of the hash has value 1. If an attribute is a length then the length entry of the hash has value 1.


  spec_is_length($element_name, $attribute_name)

Returns undef if there is no SVG element of name $element_name. NB: Because most attributes have no hints only those which have hints are present in the data structure. Therefore it cannot be distinguished if an attribute is no length or if the attribute is not an allowed attribute of the given element at all. In both cases, 0 is returned. If the attribute is a color, 1 is returned.

Only a few attributes change their behaviour depending on their element. However, they exist. To be future safe, both the element name and the attribute name have to be specified.


  spec_is_color($element_name, $attribute_name)

As spec_is_length.


The parsing of the SVG DTD in order to generate the data structures in this module was done using XML::DTD by Brendt Wohlberg. Brendt was very responsive and helpful with all issues that arose during the process of solving this task.



Lutz Gehlen, <perl at>


Copyright 2010-2011 Lutz Gehlen.

This program is free software; you can redistribute it and/or modify it under the terms of either: the GNU General Public License as published by the Free Software Foundation; or the Artistic License.

See for more information.

syntax highlighting: