RE: [xep-support] uri(file:xxx) links

From: Victor Mote (
Date: Wed May 05 2004 - 06:24:41 PDT

  • Next message: "Re[5]: [xep-support] Orphans & Widows"

    Nikolai Grigoriev wrote:

    > Victor,
    > > <fo:basic-link external-destination="url(file:aruser.pdf)">
    > > <fo:inline color="blue">Accounts Receivable</fo:inline>
    > > </fo:basic-link> ...
    > > However, when I follow the link noted above, the document
    > opens as if
    > > "fit" or "fit-height" were the setting.
    > You are right: for PDF links, we create a remote go-to action
    > in PDF that addresses the first page, and specifies scale
    > factor as /Fit.
    > The reason is, in a remote go-to action we need to explicitly
    > specify destination in the target file. And the destination
    > specifier should either provide an explicit endpoint
    > coordinate, or set the scale factor so that it fits the
    > viewport by the respective dimension.
    > To work around this limitation, I suggest adding a fragment
    > identifier to the URL:
    > <fo:basic-link external-destination="url(file:aruser.pdf#docstart)">
    > where 'docstart' is an id of some element at the beginning of
    > the tagret document. Your could begin like this:
    > <fo:page-sequence ...
    > <fo:flow ...
    > <fo:block id="docstart"/>

    That makes sense. I'll work on something along these lines.

    > This makes Acrobat jump to the respective location using the
    > scale factor specified by the named destination 'docstart'
    > _inside aruser.pdf_; typically, it simply inherits scale
    > factor from the context.
    > If you provide a non-existing fragment ID, Acrobat will jump
    > to the first page of the document (and don't even generate
    > errors). However, I am not sure this is a clean solution; I
    > believe adding a real @id to the beginning of the document is
    > a cleaner approach.

    I had already noticed that providing an empty fragment identifier caused the
    desired behavior, and agree that it is not a very clean approach. After
    digging around on this
    issue a bit, I see that, at least based on the behavior of Acrobat 6, I may
    have misunderstood the meaning of some of the document settings in a PDF
    file. The "Open To" page number seems only to be used when the document is
    explicitly & directly opened, not when it is opened (without a fragment
    identifier) by following a link from another document. I wouldn't be
    surprised to find out that this is a bug in Acrobat 6, but in any case, it
    does look like the safest thing to do is add an explicit fragment

    > > The desired behavior is for aruser.pdf to open with the "fit-width"
    > > initial zoom.
    > Thank you for providing the use case. Right now, it is not
    > evident for me how it can be done without parsing the target
    > PDF file; we are going to look into it in more details.
    > > When I try to use the Acrobat "link" tool to see the
    > properties of the
    > > link, I get the following message: "There was a problem
    > reading this
    > > document (18)."
    > I would be grateful if you could send me your PDF file
    > off-list to to examine. In general, I
    > have an impression that remote go-to actions are poorly
    > supported in Acrobat: it executes them well but creates a
    > terrible mess trying to edit them (at least Acrobat 5; did't
    > try with 6).

    I have sent (off-list) both the PDF file in question and the same document
    created with another application for reference. I definitely don't think you
    should have to parse the target PDF file for this use-case. After you
    resolve the issue causing the errors in the links, I think (based on the
    behavior of the reference file) that the behavior will be "correct",
    althought that may be by accident.

    Thanks again.

    Victor Mote

    (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
    in the body of the message to from the address
    you are subscribed from.
    (*) By using the Service, you expressly agree to these Terms of Service

    This archive was generated by hypermail 2.1.5 : Wed May 05 2004 - 06:36:38 PDT