Simple Link Observations

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

Some observations on simple links in FOP:

The rendering side of simple links is already in place in the fop_0_12_0 
distribution, so I'll refer to that. James should have the layout part 
checked in soon, I think.

Let's assume we start off with a simple XLink:

<mylink xmlns:xlink="http://www.w3.org/XML/XLink/0.9"
	xlink:type="simple" xlink:actuate="user"
	xlink:show="replace" xlink:href="somedoc.pdf">
	Some Document
</mylink>

The 'href' attribute is a URI. The attributes for "actuate" and "show" are 
demonstrative. In point of fact all the links are going to be 
user-actuated out of PDF, and whether a link causes a "new" or "replace" 
depends on Acrobat Preferences if the target is another PDF.

We'll further assume that the xsl:template for <mylink> results in this 
formatting object:

<fo:simple-link external-destination="somedoc.pdf">
Some Document
</fo:simple-link>

I'm skipping the difference between using the "external-destination" and 
"internal-destination" attributes for now, as well as other attributes. If 
you look at the portion of the XSL WD related to fo:simple-links there are 
still issues with much of this (is there a newer XSL doc than the 19990421 
WD? I haven't found one, although XPath and XSLT seem to be moving right 
along).

What the implementation currently does (and bear in mind that this is beta 
in the truest sense) is assume that the target is ALSO PDF, which is 
reflected in the above example.  I'm going to get to that in a minute.

At the moment, for visual indication of where the links are, they are 
coming in as blue solid rectangles.  Also at the moment, the linked area
is segmented into LineAreas.  Both of these may have been modified by James
in the last week or so.  The ultimate intent is for invisible links, and you 
would indicate the appearance by using other common properties, such as 
"border".

If you look at the PDFAction class you'll see that it is assuming a PDF 
target. User/developer input is requested as regards the following:

It is easy to add code into PDFAction which renders ("render" is really
the wrong word for annotations, but...) a /URI link or a /Launch link instead, 
if the target is an HTML page, or a mailto: link, or a .txt file. This 
works well enough because I've tried it. 

However, as opposed to Acrobat Exchange, where you explicitly choose from 
among those 3 options (or others), _we_ can only go off the URI as entered 
by the XML author. Worst case,and I'm not sure I like it much, is that a 
decision to select from /GoToR, /URI or /Launch would depend entirely on 
parsing the filename and looking for suffixes like '\.htm[l]', '\.pdf', 
'\.txt' etc, lowercase/uppercase. But since it's a URI we might also have
a protocol (which might be file:) and/or fragments. So it gets messy.

I could use suggestions and input on this. There's dirty ways of doing 
this, and elegant ways of doing this, and I'm looking for elegant. :-)

Naturally, any comments on other aspects of simple link implementation are 
much appreciated. It's early days and there's room for change.

Arved Sandstrom

Re: Simple Link Observations

[James Tauber <jt...@jtauber.com>]

> The rendering side of simple links is already in place in the fop_0_12_0 
> distribution, so I'll refer to that. James should have the layout part 
> checked in soon, I think.

Yes, it is my next priority.

Re: Simple Link Observations

[Sebastian Rahtz <se...@computing-services.oxford.ac.uk>]

Arved Sandstrom writes:
 > 
 > As far as links to a PDF target, if the URL contains a .pdf suffix, this
 > would supersede everything else.
 >  
are you sure? a link to "foo.pdf" is a local link, a link to
"http://www.foo.bar/foo.pdf" is a URL link. Can Acroread do a URL GotoR?

 > It's just that there is the one case, referred to above, where FOP might
 > see an "external-destination" attribute with no URI specified, in which
 > case there is the default.

sounds to me like a bad feature of the spec. external-destination=""
means the current file??? madness...

 > We'll have to poll on this one. :-) I like the idea personally of having
 > some visual feedback.

but you can provide that yourself in the XSL FO

Sebastian

Re: Using my own True-Type Font on Windows

[James Tauber <jt...@jtauber.com>]

> We have our own proprietary True-Type Font for usage on Window platform.
These
> fonts have been mainly designed for displaying diacritics in a combining
way. For
> e.g if I want to display U with umlaut. The file has actually two
characters to
> represent this. The font then displays U and does a backspace and print
the
> umlaut on top.
>
> I would like to use this font in my PDF file. How do I go about this?

I don't know how to include TrueType fonts in PDF so at the moment FOP only
supports those fonts in built into PDF (Times, Helvetica and Courier. Symbol
is built-in too but not supported)

If someone on this list knows how to embed fonts into PDF, perhaps they'd
like to work on getting support, first of all, into org.apache.fop.pdf and
then the PDF Renderer.

James
--
James Tauber / jtauber@jtauber.com / www.jtauber.com
FOP / XMLINFO.COM / XMLSOFTWARE.COM / SCHEMA.NET / XSLINFO.COM
<pipe>Ceci n'est pas une pipe</pipe>

Using my own True-Type Font on Windows

["S.Ramaswamy" <sr...@giasdl01.vsnl.net.in>]

I need your help on the following.

We have our own proprietary True-Type Font for usage on Window platform. These
fonts have been mainly designed for displaying diacritics in a combining way. For
e.g if I want to display U with umlaut. The file has actually two characters to
represent this. The font then displays U and does a backspace and print the
umlaut on top.

I would like to use this font in my PDF file. How do I go about this?

==--==--==--==--==--==--==--==--==--==--==--==--==--==
S.Ramaswamy
Matrix Infotech Syndicate
D-7, Poorti, Vikaspuri, New Delhi, 110018, India
PHONE:    +91-11-5610050,   FAX: +91-11-5535103
WEB         http://MatrixInfotech.HyperMart.Net
==--==--==--==--==--==--==--==--==--==--==--==--==--==

Re: Simple Link Observations

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

On Wed, 1 Dec 1999, James Tauber wrote:

> > We'll have to poll on this one. :-) I like the idea personally of having
> > some visual feedback.
> 
> But it should be up to the stylesheet author, not the FOP developers to
> determine what that is. eg if you want your links blue, put color="blue" in
> the stylesheet.
> 
I think we're all agreed on this, actually, as far as the visual
appearance goes. I was specifically thinking of the visual feedback once
the invisible link is actuated. Our options are None, Push, Invert and
Outline.

In any case this is something that wouldn't be hardwired, but would also
be in a properties file as the default.

Arved

Re: Simple Link Observations

[James Tauber <jt...@jtauber.com>]

> We'll have to poll on this one. :-) I like the idea personally of having
> some visual feedback.

But it should be up to the stylesheet author, not the FOP developers to
determine what that is. eg if you want your links blue, put color="blue" in
the stylesheet.

James

Re: Simple Link Observations

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

On Wed, 1 Dec 1999, Sebastian Rahtz wrote:

> Arved Sandstrom writes:
>  > I guess that one programmatic approach, then, is to take the string
>  > specified as the value of 'external-destination', and construct a
>  > java.net.URL out of it. It'll throw an exception if it's bad. And after
> 
> suppose the link is to "foo.pdf" or "file:foo.pdf". Those can be
> turned into valid URLs, but the effect of making them /URIs will be to 
> launch a browser, which will then load the PDF. But in fact you want
> the local copy of the PDF reader to simply do /GoToR
>
I guess what I'm suggesting is that constructing a URL is used ONLY for
checking that the target is actually a valid construction, and also for
conveniently retrieving bits.

As far as links to a PDF target, if the URL contains a .pdf suffix, this
would supersede everything else.
 
>  > There is also the possibility of an empty URI, which means that the
>  > destination is the current doc (the PDF), in which case we're talking
>  > about a /GoTo (default to page 0?)
> 
> surely this would be <simple-link internal-destination="..." ????
> anything external would be  <simple-link external-destination.
>
It's the actual XSL WD default. If the URI to external-destination is
unspecified, then the target is the current document (well, the source
document to be exact - if we were talking extended links this might not
be one and the same). If both
internal-destination and external-destination are specified, it's either
an error or we default to the internal-destination.

> I'd expect to treat internal-destination as a named target in the
> current PDF file
> 
No argument from me. If the URI resolves into a link pointing at the
source document then we're talking about an "internal-destination"
fo:simple-link and a resulting /GoTo PDF action.

It's just that there is the one case, referred to above, where FOP might
see an "external-destination" attribute with no URI specified, in which
case there is the default.

 > Other simple link issues: go with Inherit
Zoom? Fit In Page? What >  > highlighting? (It's currently invert).
> 
> no highlighting at all, IMHO
>
We'll have to poll on this one. :-) I like the idea personally of having
some visual feedback.
 
>  > various classes related to links also read in from a property file, which
>  > someone can edit to set their link defaults? Comments?
> 
> I think the "go with Inherit Zoom? Fit In Page?" has to be done in a
> preferences/property file. unless <simple-link gets some attributes.
> 
Yup, I personally lean this way.

I haven't had the chance to really look at it, but it's also possible that
the fo:simple-link attributes "space-above-destination-block" and
"space-above-destination-start" could be used, in some circumstances, with
PDF targets to determine a "best" view.

Arved

Re: Simple Link Observations

[Sebastian Rahtz <se...@computing-services.oxford.ac.uk>]

Arved Sandstrom writes:
 > I guess that one programmatic approach, then, is to take the string
 > specified as the value of 'external-destination', and construct a
 > java.net.URL out of it. It'll throw an exception if it's bad. And after

suppose the link is to "foo.pdf" or "file:foo.pdf". Those can be
turned into valid URLs, but the effect of making them /URIs will be to 
launch a browser, which will then load the PDF. But in fact you want
the local copy of the PDF reader to simply do /GoToR

I agree with your principle, but I suspect there are some possible bad 
consequences.

 > There is also the possibility of an empty URI, which means that the
 > destination is the current doc (the PDF), in which case we're talking
 > about a /GoTo (default to page 0?)

surely this would be <simple-link internal-destination="..." ????
anything external would be  <simple-link external-destination.

I'd expect to treat internal-destination as a named target in the
current PDF file

 > Other simple link issues: go with Inherit Zoom? Fit In Page? What
 > highlighting? (It's currently invert).

no highlighting at all, IMHO

 > various classes related to links also read in from a property file, which
 > someone can edit to set their link defaults? Comments?

I think the "go with Inherit Zoom? Fit In Page?" has to be done in a
preferences/property file. unless <simple-link gets some attributes.

Sebastian

Re: Simple Link Observations

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

On Wed, 1 Dec 1999, Sebastian Rahtz wrote:

> Arved Sandstrom writes:
>  > However, as opposed to Acrobat Exchange, where you explicitly choose from 
>  > among those 3 options (or others), _we_ can only go off the URI as entered 
>  > by the XML author. Worst case,and I'm not sure I like it much, is that a 
>  > decision to select from /GoToR, /URI or /Launch would depend entirely on 
>  > parsing the filename and looking for suffixes like '\.htm[l]', '\.pdf', 
>  > '\.txt' etc, lowercase/uppercase. But since it's a URI we might also have
>  > a protocol (which might be file:) and/or fragments. So it gets messy.
> 
> I have been around this in my TeX-based implementation of XSL FO, and
> I do exactly what you say: examine the file suffix, and the protocol
> name, to decide what to do. It's horrid but I do not see any way to
> avoid it, because Acrobat is not intelligent enough to realize that a
> URL of "foo.pdf" can be treated as a local open.
> 
> I also had to use a protocol of "run:" to specify Launch actions. yuck.
> 
I guess that one programmatic approach, then, is to take the string
specified as the value of 'external-destination', and construct a
java.net.URL out of it. It'll throw an exception if it's bad. And after
that it's a matter of using methods like getFile() and getProtocol() on
the URL object, in combination with some simple (hopefully) rules, to
figure out what link action to use.

I was thinking that the rules would explicitly try to figure out (perhaps
in this order) the following:

(1) is it a PDF target? If so, use /GoToR;

(2) If not PDF, is it a file that should get a /URI type link? Such as
HTML, XML (???), mailto:, etc? If so, use /URI;

(3) Everything else gets a /Launch, and let the system worry about it when
it tries to open the document.

There is also the possibility of an empty URI, which means that the
destination is the current doc (the PDF), in which case we're talking
about a /GoTo (default to page 0?)

And there's the possibility of a specification to a location in the same
file. Again, /GoTo, but this time with the possibility of figuring out
what page to point at, and depending on other properties of
fo:simple-link, possibly even what spot on the page.

Other simple link issues: go with Inherit Zoom? Fit In Page? What
highlighting? (It's currently invert).

This is all up in the air. A lot of it is pretty easy to do, but we need a
consensus that everyone is reasonably happy with (more exactly, not
violently opposed to), specifically on things that have to be hardcoded.

Other crazy idea - do we need to hardcode, per se? Or can we have the
various classes related to links also read in from a property file, which
someone can edit to set their link defaults? Comments?

Arved

Re: Simple Link Observations

[Sebastian Rahtz <se...@computing-services.oxford.ac.uk>]

Arved Sandstrom writes:
 > However, as opposed to Acrobat Exchange, where you explicitly choose from 
 > among those 3 options (or others), _we_ can only go off the URI as entered 
 > by the XML author. Worst case,and I'm not sure I like it much, is that a 
 > decision to select from /GoToR, /URI or /Launch would depend entirely on 
 > parsing the filename and looking for suffixes like '\.htm[l]', '\.pdf', 
 > '\.txt' etc, lowercase/uppercase. But since it's a URI we might also have
 > a protocol (which might be file:) and/or fragments. So it gets messy.

I have been around this in my TeX-based implementation of XSL FO, and
I do exactly what you say: examine the file suffix, and the protocol
name, to decide what to do. It's horrid but I do not see any way to
avoid it, because Acrobat is not intelligent enough to realize that a
URL of "foo.pdf" can be treated as a local open.

I also had to use a protocol of "run:" to specify Launch actions. yuck.

Sebastian

Re: Simple Link Observations (SECURITY)

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

 On Thu, 2 Dec 1999, John R. Brinkema wrote:

> Arved Sandstrom wrote:
> 
> >>Some observations on simple links in FOP:
> >> ...
> >> It is easy to add code into PDFAction which renders ("render" is really
> >> the wrong word for annotations, but...) a /URI link or a /Launch link instead,
> >> if the target is an HTML page, or a mailto: link, or a .txt file. This
> >> works well enough because I've tried it.
> >>...
> The /Launch capability is one of the *worst* ideas in PDF (an otherwise great
> standard).  It opens a massive security hole ... one that allow an arbitray
> command on the client system to be executed.  The command has to be on the client
> already, but there are always lots of damaging commands there to choose from now
> (i.e. under Windoz, try 'format c:').  Versions of Acrobat (I don't know about
> xpdf or other PDF
> processing tools) after version 3.01 give a warning message, but most users just
> choose the default response, which is 'go ahead and execute the command'.
> 
> Please think hard and long about the security implecations of your ideas. /jb
> 
This is a valid point, and I thank you for mentioning it.

I personally could go with just having /Goto[R] and /URI actions, and
leave out the /Launch.

The worst security problems are going to be on the most common system -
Windows. Since I don't use it myself except when I must, maybe thoughts on
this should come from Windows aficionados.

Arved Sandstrom

Re: Simple Link Observations (SECURITY)

["John R. Brinkema" <br...@teo.uscourts.gov>]

Arved Sandstrom wrote:

>>Some observations on simple links in FOP:
>> ...
>> It is easy to add code into PDFAction which renders ("render" is really
>> the wrong word for annotations, but...) a /URI link or a /Launch link instead,
>> if the target is an HTML page, or a mailto: link, or a .txt file. This
>> works well enough because I've tried it.
>>...
>> Arved Sandstrom

The /Launch capability is one of the *worst* ideas in PDF (an otherwise great
standard).  It opens a massive security hole ... one that allow an arbitray
command on the client system to be executed.  The command has to be on the client
already, but there are always lots of damaging commands there to choose from now
(i.e. under Windoz, try 'format c:').  Versions of Acrobat (I don't know about
xpdf or other PDF
processing tools) after version 3.01 give a warning message, but most users just
choose the default response, which is 'go ahead and execute the command'.

Please think hard and long about the security implecations of your ideas. /jb

                                                                            John
R. Brinkema

Administrative Office of the US Courts