| Summary: | (Hyper)Links lost on conversion to PDF | ||
|---|---|---|---|
| Product: | GhostXPS | Reporter: | Noam <noam> |
| Component: | General | Assignee: | Ken Sharp <ken.sharp> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | christinedelight.top85 |
| Priority: | P4 | ||
| Version: | unspecified | ||
| Hardware: | PC | ||
| OS: | All | ||
| Customer: | Word Size: | --- | |
| Attachments: |
A simple XPS file with a couple of links
The resulting PDF |
||
Created attachment 6328 [details]
The resulting PDF
(In reply to comment #0) > I'm having another issue with XPS->PDF conversion: when converting a document > that contains hyperlinks, the format of the links is converted successfully, > but the links themselves aren't converted. I'm left with a PDF document that > has something that *looks* like a link, but doesn't do anything when clicked. > > Debugging the code seems to suggest that the link attribute in the XPS file > (FixedPage.NavigateUri="...") is ignored. Is this a bug or a feature? I suppose arguably its a missing feature. Right now the XPS->PDF conversion is a 'best effort' conversion, and is limited to appearance only. This means that XPS features which do not exist in PDF (certain dash types, line caps and shadings, among other things) are either converted to the nearest PDF equivalent, or rendered as images. In addition document metadata such as hyperlinks is not processed. In PDF files the Link annotation is stored separately to the appearance, so a link can look as you would expect, but unless a LNK annotation is created it won't do anything. These annotations are normally created in the output PDF file by executing a PostScript pdfmark operator. When the input file is PDF the PDF interpreter (which runs in the PostScript environment) converts the PDF annotation into a pdfmark operation. The XPS interpreter doesn't (I don't think) handle hyperlinks in the input XPS document (the XPS interpreter assumes its printing the document), so there is no pass-through of that information into the output PDF file. Also, the XPS interpreter doesn't execute in the PostScript environment, so there is no way to execute a PostScript pdfmark operation. I've altered this from a bug to an enhancement, because it would be nice to be able to preserve such features as far as possible. However making the conversion more robust has a higher priority. Actually, you don't need the PS interpreter to pass pdfmark info to the pdfwrite device -- these are transmitted as a device parameter: We use a pseudo-parameter named /pdfmark whose value is an array: [ /key1 (value1) ... (CTM) /type ] The XPS parser would populate the array and call gs_putdeviceparams(). Basic implementation here 3717f49247677332b24e2b97de4eec3b6b3ad7e1 I don't have an example of a canvas or Glyphs element with a NavigateUri so I can't add the code to those. This won't work with internal links in a document, only external links. Making internal links work looks problematic. |
Created attachment 6327 [details] A simple XPS file with a couple of links Hello again, I'm having another issue with XPS->PDF conversion: when converting a document that contains hyperlinks, the format of the links is converted successfully, but the links themselves aren't converted. I'm left with a PDF document that has something that *looks* like a link, but doesn't do anything when clicked. Debugging the code seems to suggest that the link attribute in the XPS file (FixedPage.NavigateUri="...") is ignored. Is this a bug or a feature? I'll attach a simple XPS document and the resulting PDF. Thanks, Noam