Sorry, that sounded like I'm using Acrobat as my XSL-FO processor. I'm
using XEP 4.13 and FOP 0.95, and browsing with Acrobat Pro 9. When I
enlarge the page so only part of the vertical span of the page is showing,
the links scroll the page to show the title near the top of the window.
Bob S
Well, we seem to be getting different behavior. What XSL-FO processor are
you using? I'm using Adobe Acrobat Professional 9.0. Perhaps someone else
could test this as well?
Bob Stayton
Sagehill Enterprises
b...@sagehill.net
- Original Message -
From: "Tobias Anstett [k15t.com]"
Hello All,
All advice is welcome for dealing with translations.
Our current setup:
- Uses CVS version numbers for tracking (manually updated in each
translation)
- Translations include the DocBook markup
Our desired setup:
- Not use CVS numbers (we are moving to SVN)
- Have markup change
In a message dated 05/14/09 12:22:07 Pacific Daylight Time, da...@dpawson.co.uk
writes:
deannel...@aol.com wrote:
> Dave,
>
> I have a pretty simple system that assumes a directory structure like this:
>
> xml files
> xml files\images
>
> 1. When I publish FO the PDF lands in "xm
deannel...@aol.com wrote:
Dave,
I have a pretty simple system that assumes a directory structure like this:
xml files
xml files\images
1. When I publish FO the PDF lands in "xml files".
2. When I publish HTML:
- I set the "output" directory to "xml files\html"
- I copy the images from "x
Dave,
I have a pretty simple system that assumes a directory structure like this:
xml files
xml files\images
1. When I publish FO the PDF lands in "xml files".
2. When I publish HTML:
- I set the "output" directory to "xml files\html"
- I copy the images from "xml files\images" to "xml fil
Actually, I do most of my work on Linux, but it is not shared so
I have administrative privileges on it.
We have a property in our build files that specifies the path to
the directory containing the graphics. If it is empty, nothing
is done, if it is populated, that directory is created in the
You are correct, the DocBook images are relatively static, however, we use
company specific images for the admonitions, which means they will change over
time as corporate standards change.
We actually tend towards ./img, but that is simply historical accident. It is
what we started with and p
Rowland, Larry wrote:
I put a copy of our style assets directory at the root of my hard drive.
We always use the /styles/... type of path on our production pages that
are aimed at the Web.
That way if I open the file on my Windows system the styles are
available, too.
Or Linux. Makes perfec
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 ent
I put a copy of our style assets directory at the root of my hard drive. We
always use the /styles/... type of path on our production pages that are aimed
at the Web. That way if I open the file on my Windows system the styles are
available, too.
Larry Rowland
-Original Message-
Fro
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, w
| -Original Message-
| From: Eric Johnson
|
| I was wondering if someone could look at bug #1640440.
I have added some comments.
Mauritz
-
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For
DeanNelson wrote:
Dave,
I do something similar also. For HTML generation, I make sure all images
(including Docbook images) are in one place. This makes Saxon complain
about not seeing the images, but I resolve that afterwards by copying
the images to the publishing image directory.
So you
Remko Tronçon wrote:
Which works fine... so long as the reader, And Bobs site, are on line?
Eh?
Let me see if I understand your problem (sorry if I'm underestimating
your knowledge): you generate an HTML file using the docbook-xsl
stylesheets, and you want to make sure you can put the HTML fil
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,
Dave,
I do something similar also. For HTML generation, I make sure all images
(including Docbook images) are in one place. This makes Saxon complain about
not seeing the images, but I resolve that afterwards by copying the images to
the publishing image directory.
However, I have a lot of ima
> Which is my solution too Eric! No, I'm not thinking its
> the smart way to do it! I now have this set of
> graphics all over my disk and website!
- For a website, set the user parameters "navig.graphics.path",
"admon.graphics.path" (and all other image paths) to either
"/graphics/" or "http://gr
> Which works fine... so long as the reader, And Bobs site, are on line?
Eh?
Let me see if I understand your problem (sorry if I'm underestimating
your knowledge): you generate an HTML file using the docbook-xsl
stylesheets, and you want to make sure you can put the HTML file
online and make sure
We have over 15000 books in multiple languages on docs.hp.com, so we share the
assets. 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).
We can also package up the assets with a build for placem
Eric Johnson wrote:
I'm not sure how "smart" our solution is, but we copy them to per book
folder: http://example.com/book/graphics. This way we can ensure that
every book has the proper images. The same folder is used to hold
product logos and other standard images.
Which is my solution too
Remko Tronçon wrote:
How do you manage this? Anyone got any 'smart' solutions?
I'm not sure if this is what you're asking for, but take a look at:
http://www.sagehill.net/docbookxsl/Icons.html
You can specify the paths to the images; you can set these to whatever
you want (absolute/relative/fu
> How do you manage this? Anyone got any 'smart' solutions?
I'm not sure if this is what you're asking for, but take a look at:
http://www.sagehill.net/docbookxsl/Icons.html
You can specify the paths to the images; you can set these to whatever
you want (absolute/relative/full URIs, ...)
cheers,
I'm not sure how "smart" our solution is, but we copy them to per book folder:
http://example.com/book/graphics. This way we can ensure that every book has
the proper images. The same folder is used to hold product logos and other
standard images.
-Original Message-
From: DavePawson [m
You build a docbook html book|article|website.
This refers to some of the graphics in the xsl distribution.
If they are linked from your disk, to another disk location,
it breaks when you put them on your website.
How do you manage this? Anyone got any 'smart' solutions?
http://example.com/docbo
25 matches
Mail list logo
