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

[DavePawson <davep@dpawson.co.uk>]

Rowland, Larry wrote:
>  
> 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.

Yes, I can see the logic. I'm less sure how often docbook images change
but for a user that has versions of images, js, css etc this layout 
looks good.
More than usable, and scalable.

A new build then simply needs to reference a new version of some element.

> 
> 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.

Yes, I like it. Any objection to me 'stealing' it for docbook FAQ usage 
please larry?




> 
> 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. 

Yes, that makes sense, local within a ./graphics directory or similar.



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.

That would be great... if it weren't for people :-)


> 
> 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


Thanks. I'll try and knock something up tonight / in the morning on this 
lines unless you object Larry.





regards

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