OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [docbook-apps] Docbook images/graphics. Where do you keep them?


 
Actually, I was just trying to set the context -- I don't even work on that part of the production process any longer.  The smaller your publication volume the less critical the style assets delivery mechanism.  This gives us control over the visual appearance of the entire set of documents, which can be important when you have changes in  branding.

We actually version the entire directory of resources:

  /styles/5.0/
    country/
       de/
         de/
           img/      graphics specific to de_DE locale
           js/       Javascripts specific to de_DE locale
                     (the Javascript selects CSS based on 
                      browser and platform)
           styles/   CSS specific to de_DE locale 
                     (multiple, selected by Javascript)
       es/
       en/
       etc.
     favicon.ico     (this gets moved to the root of the Web 
                      exposure to make the icon work correctly)
     img/            graphics that do not need localization 
                     (here is where the DocBook graphics are)

This makes sure the graphics and other styling assets work together.

Our Ant build selects the appropriate resources based on the target selected.  We have targets for builds that are to be posted on the HP web and targets that are for captive documents that are shipped on CDs and such where the page may be viewed in an environment that cannot see the internet.  We can also pass in parameters dynamically and have a single parameter that sets all the references to graphics and style sheets to a single root directory (that has the organization described above).  Of course, given Daybook's design it would be possible to override the common source model, but we find it easier to package up what we need and ship it as a whole.

Not everything goes on the Web and not everything goes on a CD, so we have different targets in the build for each destination.  We also have packaging targets.

The builds handle the collection of assets for captive delivery (with assets) and just don't add anything for Web-based delivery.  Locale is set for a build (in the build file, rather than the document, since a number of things have to be done based on locale before and after the transforms are run on the document itself).  Locale is passed into the transform.

Graphics that are unique to a document are, of course, collected with the document whether it is going to the Web or to a CD.  Each document is complete in terms of its own graphics.  We experimented with sharing images between documents (such as block diagrams of systems) and found it too error prone (what if the initial document gets removed, that type of problem) so we make each document complete now.

We change version of the style resources in the transform, using the override when we are testing a new version of the build.

The same build environment does PDF builds, usually using SVG for the images that we can (screen shots are just PNG and photos are JPEG, unless they have callouts, which we do by overlaying them on the image using SVG).

LRR

Rowland, Larry wrote:
> We have over 15000 books in multiple languages on docs.hp.com, so we 
> share the assets.

You're just a big show-off Larry :-)


   We use a versioned directory on the Web site that has
> all our branding assets (cascading style sheets for each locale, logos, 
> admonition icons, etc). 

So at some location you'd have your logos, CSS icons etc,
under a version/logo or logos/version

Any issues referring to that or is that done in the document build?
language+version+ whatever?


  We can also package up the assets with a build
> for placement when the internet may not be available (such as on CDs) 
> but we generally produce the documents pointing at the common assets 
> folder on docs.hp.com.

For each new (say version) you build it, then load it to the hp site
as well as archive it off for CD usage? A sort of 'build/package up 
graphics' stage of docbook? Sort of makes sense.


   This is controlled by a parameter in our build
> environment that can be overridden by a user value in a parameter 
> override file that is processed when the document is built.
>  
> Regards,
> Larry Rowland

Any chance of a cut down example of that please, or am I on the right 
lines above with an ant build step to collect graphics, language 
specific parts etc?

Thanks Larry. Some neat ideas there!



regards

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]