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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
