Author Topic: Hyperlinks in document generation  (Read 1597 times)

Uffe

  • EA Practitioner
  • ***
  • Posts: 1859
  • Karma: +133/-14
  • Flutes: 1; Clarinets: 1; Saxes: 5 and counting
    • View Profile
Hyperlinks in document generation
« on: February 13, 2020, 03:28:21 am »
Hi all,


I've got a DocumentGenerator script, which incorporates an element's LinkedDocument, if any, like so:

Code: [Select]
if element.GetLinkedDocument() <> "" then
docGen.InsertLinkedDocument element.ElementGUID
end if

This works in that the linked document is indeed included in the generated document. However, EA buggers up any hyperlinks in the linked document but royally.

All hyperlinks work correctly in the linked document, first of all. I can follow them from there in EA's RTF editor, it fires up the default browser which displays the pages happily.

Bug #1: if the display text of a link contains non-English characters, EA creates multiple hyperlinks in the generated document.

So a link that displays the text Fáncie and that points to https://www.google.com, will in the generated document have turned into 3 (three) hyperlinks with the display texts F, á, and ncie, each pointing to the same URL. Since they are displayed right next to one another in Word, it looks like one and the same hyperlink, but if you edit one of them you'll see the others don't change.

Bug #2: hyperlinks in EA's internal format break completely. This is because EA doesn't strip out the $inet: from the URL when generating the document. Thus, if you create a hyperlink in the document using right-click -- Create -- Hyperlink -- Web Site (in the dialog), it gets mangled. Hyperlinks created using Document Edit -- Insert -- Hyperlink work.

The mangled links also become file links, but I'm pretty sure that's because Word assumes a malformed URL must be an internal in-Word link, or at least a file link, and tries to do the best of a bad job. Which doesn't work.

Bug #3: fragment URLs get lost completely. EA splits the URL at the '#', places the fragment identifier into the hyperlink but never puts the first part back -- the one with the protocol, server and resource. Why it does this I can't imagine. While the fragment reference is useful, the important part is actually the first bit. I can always scroll the page if I need to, but guessing which one of the X billion pages out there my fragment is at is a little harder.

Using the Word API on the resulting file, the Hyperlink object has an empty .Address, but the .SubAddress contains the fragment identifier. When Word encounters this, it once again bravely tries to turn the broken URL into a file link, but to no avail.

This is on 15.0.1512.


/Uffe
My theories are always correct, just apply them to the right reality.