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
---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org
