NAME
OpenOffice::OODoc::Styles - Document styles and layout processing
DESCRIPTION
This class is designed to handle styles, whether automatic or named, contained in styles.xml or content.xml. It inherits from the common OpenOffice::OODoc::XPath class and brings style-focused features.
This class should not be explicitly used in an ordinary application, because all its features are available in the OpenOffice::OODoc::Document class, in combination with other features. Practically, the present manual is provided to describe the style processing features of OpenOffice::OODoc::Document (knowing that these features are technically supported by the OpenOffice::OODoc::Styles component of the API).
Remember that named styles are those that the end user can see and edit using through the GUI of an interactive office software (for ex. the Stylist tool in OpenOffice.org).
Such styles usually have meaningful names and are stored in the styles.xml member. But an OpenDocument-compliant style may own two names, so-called 'name' and 'display-name'. The 'display-name' is the name as it's displayed by the office software, while the 'name' is the main identifier. Both are displayable character strings, but they often differ. For a given 'display-name', the application software is allowed to set any arbitrary 'name'. For example, with OpenOffice.org 2, the well-known pre-defined style whose display name is "Text body" is named "Text_20_body" (the space character is replaced by its hexadecimal value between two "_" characters). In the other hand, the 'name' and the 'display-name' generally don't differ when they contain letters and/or digits only. Remember that the 'name' (and not the 'display-name') is the main identifier of a style element. So, such a method as getStyleElement("style name") uses the 'name' attribute to retrieve a style descriptor and, in case of failure, it attempts to retrieve the same element by 'display-name' (unless you change this behaviour through the 'retrieve_by' document property).
Care should be taken particularly with predefined base styles in OpenOffice.org. These styles are described in styles.xml just like named styles, but they appear to the end user with localised names (in their local language), so the really displayed style name is neither the 'name' nor the 'display-name' stored attributes. For example, in the French distribution of OpenOffice.org, the "Text body" style appears as "Corps de texte", while its "display-name" is "Text body" and its "name" is "Text_20_body". This localization is hard-coded in the office software for a few predefined styles, and it's not stored in the file. However, this is not a problem for user-defined styles as the stored display-name is exactly the same as the effective display name.
There are also numerous "automatic" styles in a document which are created implicitly by the office application each time a particular set of presentation attributes is given to an element, but where no named style is referenced. Automatic styles which apply to the document body are stored in content.xml (but in an XML element isolated from the content). An automatic style's name can change randomly each time the document is edited or saved through an interactive desktop application. Applications which access automatic styles will not want to indicate them using "hard-coded" names. The best way is to retrieve each automatic style via an object that is known to use it. Using a "hard-coded" name is all right for styles created by a program (the createStyle() method requires it), but such a name should only be considered to be stable for the duration of the session. If you want a program-created style name to be then respected by OpenOffice.org, you must create it as a named style. This is no more complicated, but it is better to avoid making hundreds of styles visible to the user that they do not need to see.
There are some structural differences between the old OpenOffice.org 1.0 format and the OASIS OpenDocument (ODF) one. A few of these differences aren't made fully transparent by OpenOffice::OODoc. So, in some cases, a program including style definitions or updates doesn't produce exactly the same results with both OOo 1 and ODF documents.
The page styles are more complex than the other usual styles. A page style Some styles are more complex than others as they describe the page layout. so called "master page", can actually define a header, a footer, margins, and a background.
Page headers and footers can contain text and images; as a consequence, some of their features can be handled by OODoc::Text and OODoc::Image.
A background contains a colour and can also include a background image (several methods are possible).
Presentation of these objects is itself controlled by styles.
All of this leads to the conclusion that it is not enough just to associate each content element with a style. In reality, document styles form a rather complex network of interdependencies.
As for page styles, the OpenDocument format contains a concept which must be understood in order to use some of the following methods. By virtue of the principle of separation of content and presentation, the definition of a page style is based on two distinct objects: "master page" and "page layout". A "master page" object encompasses any page style content (i.e. the content of headers and footers) and links to a "page layout" object which describes page presentation characteristics (with large numbers of parameters from page dimensions to background colour to footnote separator size, etc.). Names which appear in the list of page styles in OpenOffice.org are actually names of "master pages". However, to work with physical aspects of the presentation, you have to access the associated "page layout".
To complicate matters, there are also header and footer styles. Each object contained in a header or footer (e.g. paragraph or image) has a style. The number and range of styles are much larger that you would imagine just looking at the style management tool in any office software. Up to a point, OODoc::Styles methods make life easier for you by masking some of this complexity.
In OODoc::Styles methods, styles are normally indicated by their logical names (which must be unique), but, except where otherwise stated, they can also be indicated by their style element reference as well. Moreover, when a method is expecting a page layout as an argument but the programmer passes it a master page instead (whether by design or by mistake), it "knows" in most cases how to automatically select the associated page layout.
OODoc::Styles allows the applications to create new styles, and not only to update existing styles. However, defining a style requires a great many attributes. Some appear in code examples in this manual, but for a full list of possible attributes for each style, you must refer to the OpenDocument specification. As a consequence, building styles from scratch by program is not a recommended practice. It's much more easy to create documents which all the needed styles through an ODF-compliant office software, and to use them as templates in the programs, knowing that it's very easy to retrieve an existing style, to copy it and to re-use it (as is or customised) in new documents.
OODoc::Styles module is designed to allow applications to manipulate any style and even create new ones. It is not recommended, however, to use it to create a presentation entirely from code. Here again, it is better to start from document templates which already contain at least a blank of each required style.
Methods
Constructor : OpenOffice::OODoc::Styles->new(<parameters>)
Short form: odfStyles(<parameters>)This constructor should not be explicitly used in ordinary applicationsknowing that all the features of the returned object are inherited byany Document object.See OpenOffice::OODoc::XPath->new() for common arguments.Returns an OODoc::XPath OpenDocument connector with additionalstyle-aware features.The member loaded by default is "styles.xml" which gives access tonamed or automatic styles associated with the page layout. The"content.xml" part should be forced if the application is to workwith styles associated with the document body (automatic stylesonly).
backgroundImageLink(page [, link])
Allows you to check the background image's link (if found) for thepage style given as the first argument. If another link is given asthe second argument, it replaces the existing link.See imageLink in OODoc::Image about links. Put more simply, a linkis the address of the graphics file which corresponds to thephysical content of the image. Even though the background imagebelongs to the "page layout", the first argument can also be eithera "master page" or a "page layout".If the second argument "link" is given, its value replaces theexisting link in the same way as with imageLink.Example:$doc->backgroundImageLink("Standard", "http://www.genicorp.com/back.jpg");If the page did not have a background image before the call, one iscreated. It must, however, be an external linked image (as in theabove example), unless the link represents the internal address ofan already loaded image. This method does not itself carry out anyphysical import of an image.See also importBackgroundImage.
createMasterPage(name, options)
Creates a new page style. Options are:'layout' => page layout name'next' => next master page style nameThe association with a "page layout" allows you to associate alayout to the page. Otherwise the page will have a default layout.Example:$doc->createMasterPage("MyPageStyle",layout => 'pm1',next => 'Standard');See the OpenDocument specification (or the 'Organizer' tab in the"Format/Page" dialog box of OpenOffice.org) if you want to know whata "Next Style" is. The optional "next" parameter simply gives the nameof a "master page", which can be the one you are currently creating.
createPageLayout(name, options)
Creates a new layout style (page layout) which can be used by a pagestyle (master page). Options are the same as for updatePageLayout().
createPageMaster(name, options)
See createPageLayout()
createStyle(name, options)
Creates a new style of any type or class (depending on options) andreturns its reference if successful.The first argument indicates the new style name which must be uniquein the document. By default, there is no automatic uniqueness check.However, if a 'check' option is set to 'true', the methodfails and produces an error message warning if the style already exists.If the external name of the style, as it could be made visible for theend-user through an OpenDocument-compliant editing software (such asOpenOffice.org), is not the same as the internal name, it may be setthrough a 'display-name' option. Without this option, the display nameis the same as the internal name.If the active OODoc::Styles object is associated with a documentcontent (content.xml), the new style is always taken to be anautomatic style. If associated with the styles.xml part, the newstyle is considered to be a named style by default. However, thecategory => 'automatic' option (or category => 'auto') allows you tospecify it as an automatic style. Please note: in the case ofcontent.xml, the "category" option is ignored as all styles areautomatic in this member.By default, the method stores a style in the form of an XML element"style:style" (which corresponds to the most commonly used contentstyles). Some style elements are indicated in a different way. The"namespace" and "type" options are available for this. If, forexample, you want to create a notes configuration style (called"text:notes-configuration" in the ODF specification), you will haveto specify the "notes-configuration" type explicitly in the "text"namespace using one of the following two options:namespace => 'text',type => 'notes-configuration'The possible options are:namespace => namespacetype => style typefamily => style family (text, paragraph, ...)class => style classparent => parent style (inherit)next => next styleIf other style "organisation" attributes (often for links to otherstyles) prove to be needed but are not on the above list, they mustbe grouped together in a hash provided by the application andindicated by a "references" option.Of course, if you create a new style, you do not just specify it intoterms of type, class or family, etc. You attribute its ownpresentation attributes which can be inherited by other styles whichcite it as "parent". These personal attributes (whose nature obviouslydepends on the style type) are all attributed by the "properties"attribute which itself is a hash provided by the application.Here is an example of a paragraph style creation$doc->createStyle("Colour",family => 'paragraph',parent => 'Standard',properties =>{'fo:margin-left' => '2cm','fo:margin-right' => '1.5cm','fo:text-align' => 'justify','fo:background-color' => '#ffff00'});$doc->setStyle($doc->getParagraph(3), "P3");This sequence gives paragraph 3 of the document a special stylewhose properties are given margins, text justification and ayellow background color (note that the ODF color codes are in RGBhexadecimal preceded by a '#', and 'ffff00' is the RGB value forfor the yellow color). This is done using a style called "Colour"(reusable later for other paragraphs) based on the "Standard" style.The names of the properties can be found in the ODF specification(some of them come from the Form Object standard, so they begin withthe "fo:" prefix). However, the given properties are related to theglobal layout of the paragraph. We could provide this new style withadditional properties related to the text content of the paragraph.But, in a paragraph style definition, the "text" properties are notstored in the same logical area than the "paragraph" properties, andwe can't set both in the same instruction. Fortunately, we can enrichany existing style at any time through the updateStyle() method:$doc->updateStyle("Colour",properties =>{-area => 'text','style:font-name' => 'Times','fo:font-size' => '14pt','fo:font-weight' => 'bold','fo:font-style' => 'italic','fo:color' => '#000080'});This new sequence gives paragraph 3 (or any paragraph using the"Colour" style) a lovely Times font in dark blue size 14 bold italics.The '-area' parameter which appears in the 'properties' hash is nota property; it's a selector which instructs the API to select the"text" property set.Note: the hexadecimal color codes used in the example could bereplaced by more user-friendly color names, according to a standard orapplication-specific RGB color table, through the odfColor() functionintroduced in the present manual chapter.If the '-area' selector is omitted, the property set whose name isthe name of the style family (i.e. 'paragraph' in the last example).The '-area' selector is silently ignored when used with OOo 1documents, and sometimes required for ODF, so you can safely use it ifyou want to write portable code. In addition, up to now, the unknownstyle attributes are simply ignored by the OpenOffice.org software,and they don't harm. However, if the document is later edited andsaved through OpenOffice.org, every unknown attribute is removed. As aconsequence, everybody can use proprietary (non-OpenDocument) styleattributes for application-specific markup.Another example:$doc->createStyle("Photo1",family => 'graphics',parent => 'Graphics',properties =>{'style:vertical-pos' => 'from-top','style:horizontal-pos' => 'from-left','style:vertical-rel' => 'page','style:horizontal-rel' => 'page','draw:luminance' => '4%','draw:contrast' => '2%','draw:gamma' => '1.1','draw:transparency' => '5%','draw:red' => '-3%','draw:green' => '2%'});The "Photo1" style defined above is of course an image style i.e. inthe "graphics" family, based on the parent graphics style"Graphics". Any images to which this style will be applied will havecoordinates which relate to the upper left edge of the page measuredfrom top to bottom and left to right. They will be presented with anincrease in luminosity of 4% and contrast of 2%, gamma correction of1.1 and 5% transparency. Moreover, 3% less red and 2% more greenwill freshen the image and highlight the vibrancy of thechlorophyll. There are yet more in the list of options.Note: In the given examples, "namespace" and "type" are not specifiedbecause the default namespace and type are appropriate here. (Restassured that this is often the case when working with text styles.)So, while OpenOffice::OODoc supports both OOo 1 and ODF with thesame API, the present version can't completely hide the differencesbetween the two formats. However, the program's logic can hide thesedifferences for the end-user, because it can know the format ofthe current document (see isOpenDocument in OpenOffice::OODoc::XPath).Defining a style can be made a lot easier by reusing an alreadyexisting style than by creating it programmatically. The simplest wayis by inheritance using the "parent" option, but the link to "parent"creates a permanent dependency (any further changes in the parent willaffect the children). OODoc::Styles offers another possibility: copythe properties of an existing style, without creating a link to aparent, using the "prototype" option. This option points to anotherstyle whose properties are then taken up and combined with the newproperties. New properties prevail over old ones if the newproperties replace existing attributes in the prototype style, justlike when they are inherited. But there is no persistent link from thenew style to its prototype.Example:$doc->createStyle("Bigger",prototype => "Colour",properties =>{'fo:font-size' => '16pt'});This new style called "Bigger" is an exact copy of the previouslydefined "Colour" style, except for the font size.The given "parent" style is not necessarily defined yet and, if thecurrent document part is "content", it can be the name of a styledefined in the "styles" member. (See getAncestorStyle() andgetParentStyle()).Generally speaking, explicit parameters passed by an application(e.g. font size) prevail over prototype's parameters.The prototype parameter can be a style name (as in the aboveexample) or a style element. If it's an element, its origin doesn'tmatter (it can be a copy of a style element previously extracted fromanother document). If it's a name, the prototype style is retrievedeither in the current document (default) or, if the 'source' optionis provided, in another document.The value of the 'source' option is another OODoc::Styles (orOODoc::Document) object. If this option is provided, createStylelooks in the indicated document for the prototype style. If 'source'is provided without 'prototype', the prototype style is supposed tohave the same name as the style to be created.If you want to create a style called "MyStyle", for example, indocument $doc1 which imitates a style called "HisStyle" in document$doc2 (where both documents are OODoc::Styles or OODoc::Documentobjects), you can do the following:$doc1->createStyle("MyStyle",prototype => "HisStyle",source => $doc2);but if you write$doc1-createStyle("MyStyle",source => $doc2);the local style "MyStyle" is built as a copy of the so-named stylein the source document (it's a direct import).Whatever the origin of the prototype style, any property can beset or redefined in the new style.Not only can you import styles available in other documents, butyou can also create automatic styles in a 'content' part whichare derived from named styles found in the 'styles' member andvice-versa.WARNING: The "prototype" option can produce unexpected results ifthe two documents are not in the same format. As a consequence,using an OOo 1 style as the prototype of an OpenDocument one (andvice-versa) should be avoided.Always be careful of dependencies. There are often dependenciesbetween styles. An application must be wary of importing styles withdirectly or indirectl dependencies on other styles which will not beavailable in the target document. Text styles are fairly easy tocontrol in this way, but table, page and graphic styles, for example,have more complex dependencies.When a font name is set (generally through a 'style:font-name'text property) in a new style, take care of the availability ofthe corresponding font declaration in the document. A font is notrendered if it's not declared (see importFontDeclaration()).See the OpenDocument specification (chapter 14, "Styles") for acomplete list of possible attributes for each type of style.However, creating sophisticated styles from scratch is *not*recommended; remember the most easy (and the less error-prone) wayconsists of creating template documents through the OpenOffice.orgGUI (or any other ODF-compliant office software) and using them asstyle libraries.
exportBackgroundImage(page [, destination])
Exports the graphics file which corresponds to the background imageof a page style where the image exists and is internal to theOpenOffice.org archive. (A linked image is obviously not exportablesince it is not actually present in the document.) See theexportImage method in OODoc::Image for export details.Example:$doc->exportBackgroundImage("First Page", "C:\Images\backgrnd.jpg");
getAncestorStyle(style)
Returns the name of the primary known ancestor of the given style.If the style has a standalone definition (i.e. it's its own ancestor),the method returns it's own name.This method returns the ancestor name as it's known in the currentdocument space. The genealogy is not followed out of the scope ofthe current XML part.For example, if we have an automatic paragraph style "P1", defined inthe "content" member and derived from "Text body", the returnedancestor name will be "Text body". However, "Text body" itself couldbe a derivative of "Standard". But "Text body" is defined in the"styles" member, so its definition (including the name of its parentstyle) is out of the scope.As a consequence, in a regular ODF document, there are 2 possiblesituations:- if the current space is "styles", the returned style name is reallythe name of the primary ancestor, because a style defined in thisspace can't inherit from anything elsewhere;- if the current space is "content", the returned value can be thename of a style defined elsewhere.A possible check is a simple call to getStyleElement() with thereturned ancestor name. If getStyleElement() returns undef, thenthe ancestor style is not defined in the current space (and, ifneeded, we could reach it the "styles" member, if we currently workwith the "content" member).Beware: the returned name is the main name (identifier), and not thedisplay name.See also getParentStyle().
getAutoStyleList([options])
Returns a list of automatic style elements in the current document.By default, only "style" type elements in the "style" namespace arereturned. You can select special styles using the "namespace" and"type" options.For example, if you want to get a list of number styles (namespace"number", type "number-style"), do it like this:my @styles = $doc->getAutoStyleList(namespace => 'number', type => 'number-style');
getAutoStyleRoot()
Returns the element that contains all the automatic style elements.See also getNamedStyleRoot().
getBackgroundImageAttributes(page)
Returns the attributes of the given page style's background image(if any), in the form of a hash (attribute => value).
getBackgroundImageElement(page)
Returns the element reference of the given page style's backgroundimage (if found).
getDefaultStyleAttributes(default_style)
Returns the given default style's attributes (if any). Defaultstyles are generally "paragraph" and "graphics". See alsoupdateDefaultStyle().
getDefaultStyleElement(family)
Returns the default style element's reference given by its logicalname.A default style describes default values assigned to certainattributes of a given style family.For example, to get the default paragraph style of a document, use:my $def_para = $doc->getDefaultStyleElement("paragraph");
getFontDeclaration(fontname)
Returns the font declaration element corresponding to the given fontname, or undef if the font is not declared in the current document.Example:unless ($doc->getFontDeclaration("Times New Roman")){$doc->importFontDeclaration($doc2, "Times New Roman");}See also importFontDeclaration().
getFontDeclarations()
Returns the full list of the font declaration elements present inthe document.The following example prints every declared font name:foreach my $fd ($doc->getFontDeclarations){print $doc->getFontName($fd) . "\n";}
getFontName(font_decl)
Returns the name of the given font declaration element.Returns the argument as is if this argument is the name of a declaredfont, or undef if the name is unknown.
getFooterParagraph(masterpage, number)
In a text document, returns a footer paragraph's reference, if themaster page has a footer and the paragraph exists. Arguments aremaster page and paragraph number.Caution: the first argument can't be a page number, knowing thatprintable pages are dynamically created by the office software anddon't exist in the stored document.
getHeaderParagraph(masterpage, number)
Like getFooterParagraph, but for a header.
getMasterPageElement(page)
Returns a master page element reference whose logical name is given,or undef if the page style is not found. You can also pass anelement reference instead of a name. In this case, the method's roleis simply to check if the element is indeed a master page type. Ifso, it returns the argument as is. If not, it returns undef.Look at the DESCRIPTION part of the present manual chapter for a fewexplanations about master pages (and, of course, feel free to dig inthe OpenDocument specification for details).This method should preferently be used on the 'styles' member; itdoesn't generally make sense with the 'content' member, knowing thatthe master pages are generally described as named styles.
getMasterStyleList([options])
Returns a list of master styles in the current document. By default,the list contains the master page elements.Other kinds of styles may be retrieved, according to the 'namespace'and/or 'type' options (see getStyleElement()). But the search spaceis limited to the master styles area, whatever the type and thenamespace.Like getMasterPageElement(), this method makes more sense on 'styles'members than on 'content' ones.
getMasterStyleRoot()
Like getNamedStyleRoot(), but the returned element contains themaster style descriptors instead.
getNamedStyleList([options])
Returns a list of named styles in the current document, using thesame options as for getAutoStyleList. By definition, inOpenOffice.org documents this list should be empty in all elementsexcept styles.xml.
getNamedStyleRoot()
Returns the root element of the named styles area. In other words,this method retrieves the element that contains all the named styleelements, with the exception of the master styles.This element could be, for example, copied from a document to anotherone in order to use exactly the same named styles (user-defined orprovided with the office software) in both.
getOutlineStyleElement(level)
Returns the outline style descriptor related to the given outlinelevel. The returned element is available for subsequent get/setoperations using getAttributes(), setAttributes(), and so on.See also updateOutlineStyle().
getPageLayoutAttributes(page)
Returns the description of a page layout. The argument can beeither a page layout directly or a master page style whichrefers to it.The structure of returned data is a hash of hashes. It contains fourelements, each of which is a hash. As follows:- "references": style reference attributes with at least itsname and possibly its links to other styles.- "properties": background description (dimensions, orientation,margins, colour, etc.).- "header": presentation attributes for the header.- "footer": presentation attributes for the footer.- "footnote-sep": footnote separator attributes.- "background-image": background image attributes.Attributes are displayed according to OpenOffice.org specifications.
getPageMasterAttributes(page)
See getPageLayoutAttributes()
getPageLayoutElement(page)
Returns the page layout element reference from a search argumentwhich can be either a logical name or a page style reference. If theargument is a master page, the method returns the corresponding pagemaster.
getPageMasterElement(page)
See getPageLayoutElement()
getParentStyle(style)
Returns the name of the parent of the given style, or undef if thestyle has a standalone definition (without inheritance). The returnedname, if any, is the identifier of the parent style, which can differfrom its display name.The returned parent name can be the name of a style defined elsewhere(or not defined yet).See also getAncestorStyle().
getStyleAttributes(style)
Returns a style's description (other than a page style) given as alogical name or reference.The structure of returned data is a hash of hashes. It contains thetwo following elements:- "references": style reference attributes with at least itsname and possibly its links to other styles (either its family,parent style, class and/or next style).- "properties": description of the presentation characteristicsfor this style (and which depend on the type of object the styleis applied to).Remember that this structure can be used directly by an applicationto create or update another style.
getStyleElement(style_name [, options])
Returns a style element's reference using its name, or undef ifno style owns the given name in the current context. Remember thata style can be used in the 'content' context while its descriptor(i.e. the style element) is defined in either the 'styles' contextor the 'content' one. If the application doesn't know where theneeded style is defined, it must call getStyleElement() in both.If the first argument is already an element reference, it returnsthe argument if it is indeed a style element, and undef if not, sothis method could be used in order to check if a given element isa style element or not.By default, the style name is sought amongst "style" type elementsin the "style" namespace. If an application is looking for a specialstyle (e.g. page or number), then it can pass the optionalparameters "namespace" and/or "type". See the section on createStylefor these concepts.A search is of course limited to automatic styles if the current XMLdocument is "content". If the document is "styles", the search for thename is made in all styles by default. You can, however, limit itwith the "path" parameter where "path" equals "auto" to search inautomatic styles or "named" in named styles.The name is a mandatory property, and the main identifier of any stylein ODF-compliant documents. But an additional property, so-called'display-name', is sometimes provided by the applications. The'display-name' property, if provided, is made visible for the end userby the office software (for example in the stylist box ofOpenOffice.org) while the primary name is hidden. By default,getStyleElement() looks for a style whose primary name matches thegiven name, then, if the query fails, it tries to retrieve the styleaccording to its display name. However, if the "retrieve_by" propertyof the connector is set to 'display-name', the display name becomesthe preferred identifier.If a "retry" parameter is provided and set to "false" or any othervalue than "1" or "true", no double query is done. In other words,if the first query (by primary name or by display name, according tothe value of the "retrieve_by" property of the connector) fails, themethod returns immediately without trying any other query. The defaultvalue is "1" (true). You should set it to "0" or "false" in order tosave some computation time if, for example, your application doesn'tneed to take care of the possible differences between display namesand internal names.
getStyleList([options])
Combines the results of getAutoStyleList and getNamedStyleList (sameoptions).
importBackgroundImage(page, filename [, link])
Imports a background image into the given page style from anexternal file.The page style can be either a page layout or a master page. Anoptional link can be inserted (e.g. to reuse an existing link). SeebackgroundImageLink or imageLink (in OODoc::Image) for informationabout links. Otherwise, an internal link under "Pictures/" iscreated by default and takes the name of the source file.Returns the link if found, undef if not.Caution: the actual import is not made until a save is called (seeimportImage in OODoc::Image).
importFontDeclaration(doc, fontname)
importFontDeclaration(xml_string)
In the first form, retrieves a font declaration in another documentand installs it in the current document. The first argument is aOODoc::Styles or OODoc::Document object.Example:my $source = odfDocument(file => "source.odt", part => "styles");my $target = odfDocument(file => "target.odt", part => "styles");$target->importFontDeclaration($source, "Helvetica");In the second form, the single argument is the XML stringcontaining a font declaration.The following example creates a declaration for the "Comic Sans MS"font in an OpenDocument:$doc->importFontDeclaration('<style:font-face ' .'style:name="Comic Sans MS" ' .'svg:font-family="Comic Sans MS" ./>');This last import feature is not mainly provided in order to encourageraw XML coding! Be careful, the XML font declaration syntax is notexactly the same with the two supported document formats. This featureshould be used in order to import previously exported font declarations(see exportXMLElement in OODoc::XPath).A font declaration must be imported if it's used in a newlycreated style and not currently available in the target document.
masterPageExtension(page, extension_type [, element])
This method allows the user to get or set an extension to an existingmaster page. The most used extensions are "header", "footer","header-left", "footer-left", but any other key could be provided(warning: there is no ODF-compliance check, so any application-specific tag is allowed, knowing that any provided keyword will beautomatically prefixed by "style:" in the generated XML).See masterPageFooter(), masterPageFooterLeft(), masterPageHeader(),masterPageHeaderLeft(); these methods can be regarded as synonymsfor masterPageExtension() with the four listed extension types.
masterPageFooter(page [, element])
Returns the given page style's footer element reference (masterpage) or undef if not found.If the second argument is a content element, it is added to thefooter. If the footer does not exist, it is created.
masterPageFooterLeft(page [, element])
Returns the given page style's footer left element reference (masterpage) or undef if not found.A "footer left" element can be used to specify different content forleft pages, if appropriate. Unless a footer left element is definedin the master page, the content of the footers on left and right pagesis the same.If the second argument is a content element, it is added to thefooter. If the footer does not exist, it is created.
masterPageHeader(page [, element])
Returns the given page style's header element reference (masterpage) or undef if not found.If the second argument is a content element, it is added to theheader. If the header does not exist, it is created.
masterPageHeaderLeft(page [, element])
Returns the given page style's header left element reference (masterpage) or undef if not found.A "header left" element can be used to specify different content forleft pages, if appropriate. Unless a header left element is definedin the master page, the content of the headers on left and right pagesis the same.If the second argument is a content element, it is added to theheader. If the header does not exist, it is created.
pageLayout(master_page [, page_master])
Returns or modifies the layout of a given page style (master page).If the second argument is given, it replaces the old page layout value(i.e. it changes the layout of the page without changing the header orfooter content.
pageMasterStyle(master_page [, page_master])
See pageLayout()
removeStyleElement(style [, options])
Deletes the given style. The argument and options are the same asfor getStyleElement. The method returns "True" (1) if successful orundef if the style is not found.
selectStyleElementByFamily(family [, options])
Returns the first (or only) available style in the given family(using the "family" attribute), or undef if not found. Options arethe same as for getStyleElement.Example:my $style = $doc->selectStyleElementByFamily("graphics",type => 'default-style');selects the element which describes the default graphic style.This method is useful for selecting styles whose "family" attributeis their identifier (and which do not have a "name" attribute). Forexample, this is the case for default styles where there is normallya default style for the "paragraph" family and another for the"graphics" family. In the above example, we used the "type" optionwhere the type is "default-style" and not "style". We did not usethe "namespace" option because it would be pointless to know thatthe default style namespace is just the default namespace ("style").
selectStyleElementsByFamily(family [, options])
Like selectStyleElementByFamily but returns a list of elements whichbelong to the given family. The "family" argument is treated as aregular expression, so an application must therefore give theappropriate meta-characters if the search is to be limited to theexact family name.
selectStyleElementsByName(name [, options])
Returns a list of styles whose names match the first argument (whichis treated as a regular expression). Options are the same as for theother selectStyleElementsXXX methods.
setBackgroundImage(page, options)
Inserts or replaces a background image in a page style. The "page"argument points either to the page layout directly, or to the masterpage to which it refers. Options point to the graphics object andhow it is presented. The returned value is the created or modifiedbackground image's element reference (seegetBackgroundImageElement).You should first indicate the graphics file which contains the imageand whether it will merely be linked to the page by reference, or ifit has to be physically imported into the OpenOffice.org file. To"link" the image, you supply its address using the "link" option. Toimport it, you supply the image using the "import" option.Examples:$doc->setBackgroundImage("First page",import => "C:\Images\Logo.jpg");$doc->setBackgroundImage("First page",link => "C:\Images\Logo.jpg");These two calls produce the same effect, but the second only insertsa link to the image.Remember that if by error an application supplies both the "link"and "import" options, the "import" option is the one that prevails.The other options control the import of images as backgrounds. Bydefault, OODoc::Styles installs the image in the center withouttiling and with an automatic update-on-load attribute if the imageis by external link. You can choose other options using theOpenOffice.org standard vocabulary.To link a background image which is stretched to fit the entirepage, use the following:$doc->setBackgoundImage("First page",link => "C:\Images\back.jpg",'style:repeat' => 'stretch');
styleName(style_element [, name])
styleName(name [, options])
The first form checks that the given argument is indeed a "style"element reference and, if it is, returns its name (undef if not). Ifa name is given as the second argument, it replaces the style name.In the second form, the current style name is given. In this case,and without any other arguments, the method only checks if the givenname is indeed a style and returns a positive result (undef if not).It is still possible to change its name using this form, by usingthe "newname" option. With this form, some other options allow youto choose the namespace, type and category (automatic or named).These options are "namespace", "type" and "category" (seegetStyleElement for these concepts). Without these parameters, thedefault values are the same as for getStyleElement.Beware: the only recognized style name here is the main style name,which can differ from the display name.
styleProperties(style [, options])
This method is for checking and updating the formatting propertiesof a given style.It is more limited than updateStyle, but easier to code. ThestyleProperties method accesses only the style's formattingattributes and does not touch its references, such as its name, classor family (see getStyleAttributes).With no options, the current style's properties are simply returnedin the form of a hash in which the keys are attributes belonging tothe OpenOffice.org standard vocabulary and which depend on the typeof object. The same data structure can be used to modify a style'sproperties by passing options as a hash. This structure is the sameas the sub-hash "properties" of getStyleAttributes or updateStyle.If you wanted to redo the style we called "Colour" (see createStyle),for example, changing the colour of the characters to red andreplacing the italics with standard font, you could do it as follows:$doc->styleProperties("Colour",'-area' => 'text','fo:color' => odfColor("red"),'fo:font-style' => undef);This short sequence sets the "fo:color" attribute to red and clearsthe "font-style" attribute. Remember that in RGB notation, thequantity of red is given by the first two hexadecimal digits, whichhere are set to maximum, and by setting the green and blue to zero.The "font-style" attribute had previously been set to "italic".Here, the 'area' option is neutral if the document format is OOo,but it must be set to 'text' for an ODF document, because all thatis related to characters belongs to the 'text' area in a paragraphstyle (see below).styleProperties returns all the style's properties but only modifiesthose that have been set using options. To clear an existingproperty without giving it a new value, you must pass thecorresponding option giving it a null value.If the current document is an OASIS Open Document, an additional"-area" option should be provided, because a style's properties maybe stored in logical parts. For example, in a paragraph style, someproperties apply to the paragraph itself, while some other ones applyto its text content (and some text properties can have the same nameas some paragraph properties). The default value is the name of thestyle family. For example, if the style family is "paragraph", the"paragraph" part is selected by default. Because it updates fontattributes (that are text properties), the example above couldn'twork against an Open Document without an additional "area" optionwith the appropriate value:$doc->styleProperties("Colour",'-area' => 'text','fo:color' => "#ff0000",'fo:font-style' => undef);After creating a new paragraph style in an Open Document, this methodshould be used in order to set the properties which have not been setby createStyle because of the separation in two areas. In thefollowing example, the 'paragraph' properties are directly set withcreateStyle, then the 'text' properties are set with styleProperties:my $style = $doc->createStyle("CenteredStyle",family => 'paragraph',parent => 'Standard',properties =>{'-area' => 'paragraph','fo:text-align' => 'center','fo:margin-left' => '0.5cm','fo:margin-right' => '0.5cm'});$doc->styleProperties($style, '-area' => 'text','fo:color' => oo2rgb("blue"),'fo:font-weight' => 'bold','style:font-name' => 'Times New Roman');Note: According to the OASIS OpenDocument v1.0 specification,any arbitrary custom attribute could be created in anyone of thestyle's properties area, and *should* be preserved by conformingapplications when editing the document. However, up to now, anycustom property is lost as soon as the document is edited throughOpenOffice.org.The "-area" option is silently ignored with OOo 1 documents.
switchPageOrientation(page)
Switches a portrait page to landscape and vice-versa.The argument is a page style (page layout or master page).'portrait' and 'landscape' are not style properties. The logic ofthis method is very simplistic: it makes a swap between the heightand the width of the page.CAUTION: don't try to give a page number as the argument. Thismethod apply on a page style (i.e. master page) and not on areal page selected by its number.
updateDefaultStyle(family, options)
Modifies the default style for the given family according to anoptions hash given by the application. The family is generally"paragraph" or "graphics".Options are given according to the OpenOffice.org style attributesvocabulary.The following example shows how to change the font, font size anddefault tab stops in the text:$doc->updateDefaultStyle("paragraph",'fo:font-name' => 'Helvetica','fo:font-size' => '10pt','style:tab-stop-distance' => '1.5cm');
updateOutlineStyle(level, properties)
updateOutlineStyle(outline style element, properties)
Allows any change in the direct attributes of an outline style.The new properties must be provides through a hash, where each keyis an OpenDocument-compliant attribute.The following example changes the numbering prefix and suffix, andthe numbering format for the level 1 list elements, so their numberingwill look like "[A] ", "[B] ", "[C] ", ...$doc->updateOutlineStyle(1,'num-prefix' => "[",'num-suffix' => "] ",'num-format' => "A");See the OpenDocument specification for the full set of possibleattributes. Any attribute provided without namespace prefix (i.e.not including a ':'), such as those in the example above, areautomatically prefixed by 'style:'; other attributes must be providedwith their prefixes.Caution, some outline presentation characteristics, such as bulletstyle, are not directly under the control of this element. They dependon children "style:*-properties" elements.
updatePageLayout(page, options)
Modifies all types of page presentation style characteristics (pagemaster). The style given as the first argument can be either theappropriate page layout style directly, or a page style (masterpage) to which it refers.Options can be passed in the form of a hash of hashes (each optionitself points to a hash containing the base attributes). The fourtop-level elements are as follows:references => name, family, etc.properties => global presentation attributesheader => header presentation stylefooter => footer presentation stylefootnote-sep => footnote separator stylebackground-image => backgrnd.jpg image characteristicsThe "references" branch will not generally be used unless you wantto change the style's name.This data structure is the same as returned bygetPageLayoutAttributes(). A combination of these two methods allowsyou to copy the characteristics of one page style to another easily,especially when you want to apply the page setup of one document toanother. When you only want to modify an existing style however, youonly need to specify the attributes which you want to change.A "prototype" option allows you to clone the characteristics of anexisting page layout. This option can indicate either an existingpage layout reference, its logical name, or even the reference orlogical name of a master page which refers to it. Only the firstmethod is supported if the prototype page layout belongs to anotherdocument. The style name is not replaced by the prototype stylename. See also createStyle about using a prototype style.The following example shows the code required to change severalproperties of the "Right page" style i.e. top margin width,background colour, maximum footnote height, minimum header heightand the colour and width of the footnote separator.$doc->updatePageLayout("Right page",properties =>{'fo:margin-top' => '2.5cm','fo:background-color => '#88eecc','style:footnote-max-height' => '3cm'},'footnote-sep' =>{'style:width' => '0.02cm','style:color' => '#0000ff'},header =>{'fo:min-height' => '2cm'});Once again, it is better to start with a getPageLayoutAttributes()of an existing page than to create all your styles from code.
updatePageMaster(page, options)
See updatePageLayout()
updateStyle(style, options)
Modifies the characteristics of an existing style.Options are the same as for createStyle() except for "category","namespace" and "type" which cannot be changed in an existing stylesince they form part of its basic identity. A style's logical namecan, however, be changed.The first argument can be either a style name or a style element.The second way should be preferred when the program already ownsthe element (obtained, for example, through getStyleElement() orcreateStyle()).In the 'properties' structure, the 'area' switch is required withODF (OOo 2) documents if the property area is not the default one(see styleProperties and createStyle about the 'area' option).You can use the "prototype" option to update a style with anotherstyle's characteristics, but this option does not replace thestyle's name with the prototype's name. Be careful, the "prototype"option doesn't work for any kind of style, and it's not recommendedin this method. The best approach for replicating an existing styleconsists of creating a new style with the "prototype" option (seecreateStyle).By definition, the style already exists and can be indicated equallywell by reference or by name.Returns the characteristics of the modified style, as ingetStyleAttributes.
Exported functions
odfColor($red, $green, $blue) =head3 odfColor("$red,$green,$blue") =head3 odfColor($colorname)
Converts an RGB or named colour in ODF-compliant hexadecimal format(6 digits after a leading '#'). The 1st form has the same effect asthe rgb2hex() function of the Color::Rgb Perl module.The resulting value can be used to set any colour attribute in astyle.In the first form, the 3 arguments are the conventional numeric RGBvalues (between 0 an 255). In the second form, the only one argumentis a string containing 3 comma-separated RGB values. In the thirdform, the given string is the symbolic name of a colour (the namemust be an existing one in the %COLORMAP hash).Example:ooLoadColorMap("D:\MyDocuments\Colors.txt");$doc->styleProperties("HighColors",'fo:color' => odfColor('black'),'fo:background-color' => odfColor('yellow'));If the argument seems to be already an hexadecimal RGB string (i.e.it begins by "#"), odfColor() checks it and returns it unchanged ifit's a regular RGB value, or undef if not.Synonym: rgb2oo().
odfLoadColorMap($filename)
Populates the %OpenOffice::OODoc::Styles::COLORMAP hash from thecontent of an RGB file. This file defines a colour dictionary.Without argument, the content of the $COLORMAP variable is consideredas the filename.Each line must contain 4 space-separated fields. The 3 first fieldsrepresent, respectively, the red, green and blue values of a colourand must be positive integer values in the 0-255 range. The remainderof the line is considered as the symbolic name of a colour (it cancontain spaces). Example:144 238 144 light green139 0 139 dark magenta255 105 180 hot pink255 99 71 tomatoSuch a file is sometimes provided in a system directory (for example/usr/lib/X11/rgb.txt in some Unix systems). In any case, the userscan easily find and download it somewhere. For example, a convenientrgb.txt file is provided with the Color::Rgb Perl module (CPAN).When a COLORMAP is loaded, the programmer can provide symbolic, user-friendly names in place of RGB values to the odfColor() function.Without argument, the content of the $COLORMAP variable is consideredas the filename.When the OpenOffice::OODoc::Styles module is loaded as a consequenceof a "use OpenOffice::OODoc" statement, ooLoadColorMap() isautomatically executed if a valid filename is provided in the<Styles-COLORMAP> element of the "OODoc/config.xml" file.
oo2rgb($oocolor)
Returns the conventional RGB value of an OOo-encoded colour.See rgbColor().
ooLoadColorMap($filename)
Synonym of odfLoadColorMap().
rgb2oo($red, $green, $blue) =head3 rgb2oo("$red,$green,$blue") =head3 rgb2oo($colorname)
See odfColor().
rgbColor(odf_color)
Converts an ODF-color code into a decimal RGB code or, accordingto a mapping file, into a plain text conventional color name.In array context, returns a 3-element array containing the red, green,blue decimal values of the colour.In scalar context, returns either a string with concatenated, commaseparated red, green, blue values, or, if these values exactly matcha known colour (according to the current %COLORMAP), the correspondingsymbolic name.This function can be used to display or compute separately the RGBvalues of any colour attribute of a style, or to export these valuesto an image processing software. It produces the same result as thehex2rgb() method of the Color::Rgb Perl module.rgbColor() is a synonym of oo2rgb().
Properties
The 'retrieve_by' option, set to 'display-name', can be providedin order to use the display name instead of the primary name asthe first style identifier.The %COLORMAP hash, defined as a class variable, contains a nameto RGB translation table. When loaded, it allows the rgb2oo() functionto use symbolic names in place of RGB values.The keys are symbolic, user-defined colour names, and the values arestrings containing the concatenated, comma-separated RGB values.Example:%OpenOffice::OODoc::Styles::COLORMAP{'antique white'} = "250,235,215";By default, this hash contains a short, arbitrary set of colourdefinitions such as 'red', 'green', 'blue', 'white', 'black' and a fewothers. The user can populate it from an external RGB file, throughthe ooLoadColorMap() function previously described, and/or throughprogram instructions like the example above.
AUTHOR/COPYRIGHT
Developer/Maintainer: Jean-Marie Gouarne <http://jean.marie.gouarne.online.fr>
Contact: [email protected]
Copyright 2004-2009 by Genicorp, S.A. <http://www.genicorp.com>
Initial English version of the reference manual by Graeme A. Hunter ([email protected]).
License: GNU Lesser General Public License v2.1