Jump to content

Recommended Posts

Hi everybody,

this isn’t a technical question in the proper sense of the word, but I would like to gather some opinions. At the moment, I am typesetting a support document for a non-profit, and I wonder how to typeset long URLs for PDF export in the best possible way.

  • First, I believe it necessary to avoid ambiguity, in particular with respect to hyphens. By default, Publisher will add a line break to a long URL at the place where a hyphen occurs (A). But that might create ambiguity with respect to the use of hyphens in running text, where hyphens are not to be considered part of the forms they separate. Looking at (A), one might read “criticalservices” rather than “critical-services” as is intended. Since hyphens are part of the forms from which URLs are built, I would never break a long URL after an occurrence of a hyphen, but only after occurrences of signs like “/” (slash), “_” (underscore) and similar ones (B).
  • As an aside, I believe one can also send a query string to a new line as in (D), rather than adding a line break as in (C).

Now, the problem is what users do with URLs that are present in a PDF document they download from the internet.

  • Some PDF reading applications will automatically interpret a string that looks like a URL as a clickable URL. But when I manually add a line-break where it is semantically best for the human reader, the PDF app will consider only the part of the URL before the line break as being the intended URL and neglect the part that is in the next line.
  • When a human reader uses a PDF app that does not automatically interpret certain strings as URLs, he or she might be tempted to highlight the entire string, copy it, and paste it into the address line of a browser. But then my line break will be added to the address line as a character not permitted for URLs, and hence the URL will not be recognised.

So the only solution seems to be adding a hyperlink that spans all of the lines of my URL. Unfortunately, there doesn’t seem to be a way to do that automatically in Publisher, and using New Hyperlink … will never remember the choice I made for the hyperlink type before. It will always present me with Hyperlink Type: Page first. So it becomes incredibly cumbersome to typeset a document with hundreds of URLs in Publisher.

And it seems neither links in PDF documents nor links in Word files are currently understood by Publisher. They are not listed in the Hyperlinks panel, but only decorated with an underline. So there isn’t an export-import solution either.

Hence, I wonder if there is a good solution for creating documents with hundreds of URLs in Publisher. Maybe someone has an idea. Any comments and ideas would be appreciated. :)

Alex

URLs.png.e3bac5703441a55f9b35684bdbf6d7ab.png

Type.png.c07ab24a9f44440ea7564c5e2593168a.png

Share this post


Link to post
Share on other sites

Use the URL not the Page

654872231_ScreenShot2019-05-14at12_40_01PM.thumb.png.9806a6806afef01a805382b42acd0a73.png

I include a sample document and a PDF for your edification.

url test.afpub

url test.pdf


MacBook Pro (13-inch, Mid 2012) Mac OS 10.12.6 || Mac Pro (Late 2013) Mac OS 10.14.5

Affinity Designer 1.7.0 | Affinity Photo 1.7.0 | Affinity Publisher beta 1.7.0.384 | Affinity Photo beta 1.7.1.138 | Affinity Designer Beta 1.7.0.14

Share this post


Link to post
Share on other sites

Oh, I know that, Old Bruce. :) 

I do understand how to add URLs. My problem is just that Hyperlink Type: Page will always (!) show up first, when I add a new hyperlink. I will always have to go to the panel menu, change the hyperlink type to URL, paste my URL, change the character style, and then … only then … I can click Okay. I really don’t know how I will be able to do that a hundred times and more. :(

 

EDIT I changed my screenshot above to make my issues more clear.

Share this post


Link to post
Share on other sites

If the Serif developers need a suggestion rather than a discussion, I would suggest the following:

  • Add an option to automatically interpret URL strings as links as it is the case in Apple’s Pages app, for instance. Make this option a choice for the user. Don’t automatically convert strings to links.
  • Add a highlight to links in a frame that can be switched on. Add handles to the highlight that can be dragged to redefine the string to be working as a link. See my illustration below.
  • Make the New Hyperlink … popup remember the last settings.
  • Define a new way to add line breaks to strings, such that copying a string containing such a line break does not copy the line break to the string. That would solve the problems with people copy-pasting URLs from PDFs to browser address lines.

Thanks for considering … :)

Draggable.png.1bd5ec999fec84c530c232cf76486657.png

Share this post


Link to post
Share on other sites

I could imagine the last point to work in the following way. Add the following options to paragraph styles:

  • [   ]   Ignore hyphens for line breaks
  • Allow (prefer) soft line breaks after [_____________________________]

The first one would be a simple checkbox, the second one an input for characters. Then we could define, for instance, that the string

  • website.com/parent-folder/index.asp?=query

would not be broken after the hyphen, but only after the slashes. The query string would present a slight problem, if we want to have a line break before the question mark, but I am sure you could come up with a useful solution for that. :)

Share this post


Link to post
Share on other sites
17 hours ago, A_B_C said:

Hence, I wonder if there is a good solution for creating documents with hundreds of URLs in Publisher.

You might want to use no linked element at all but just text, optional visually formatted as link.

Nowadays it appears many tools recognize it a link by its content structure (starts with "http" for example).

See in this PDF:  left hyperlinked – right just text:

170312-1 url hyperlink text.pdf


macOS 10.12.6,  Macbook Pro 15" + Eizo 24"

Share this post


Link to post
Share on other sites
1 hour ago, thomaso said:

Nowadays it appears many tools recognize it a link by its content structure (starts with "http" for example).

See in this PDF:  left hyperlinked – right just text:

170312-1 url hyperlink text.pdf

I'm not so sure. The default Mac implementation (Preview and in browser PDF) only considers the first line of the text-only URLs in your sample file, and they are visually formatted differently. The ones on the left are clearly link (blue text with underline), while the ones on the right are just plain black text, with the only difference from standard text being that the pointer changes to the hand cursor when hovering over the first line of each URL.

Share this post


Link to post
Share on other sites

@ garretm30, what a pity, indeed, it works only for one-liners.– Sorry, I should have tested more before posting.


macOS 10.12.6,  Macbook Pro 15" + Eizo 24"

Share this post


Link to post
Share on other sites
5 hours ago, thomaso said:

… what a pity, indeed, it works only for one-liners …

Yes, indeed, as described in my initial post, that’s the main problem with adding manual line breaks to long URLs. :(

 

On 5/14/2019 at 9:32 PM, A_B_C said:

Some PDF reading applications will automatically interpret a string that looks like a URL as a clickable URL. But when I manually add a line-break where it is semantically best for the human reader, the PDF app will consider only the part of the URL before the line break as being the intended URL and neglect the part that is in the next line.

:( !

Share this post


Link to post
Share on other sites

A related problem is the use of ligatures in typeset URLs strings. As long as your plain text in the PDF, not backed by a hyperlink, contains a ligature character, such as the character “f_i” in your example, Preview will only consider the part before the ligature as specifying a URL. Hence, you end up with

https://www.typogra

in your example, and you get a “Server not found” message. All that cries for a better solution. C’mon, dear developers, that is an opportunity to shine … :):)

Typo.png.6a923c074a9aa01d2e135c7b57571916.png

Share this post


Link to post
Share on other sites
4 hours ago, A_B_C said:

Preview will only consider the part before the ligature as specifying a URL.

To me, too. – Whereas this, I guess, is an issue of Apple's Preview.app – it does not happen when clicking the link in Acrobat: there the text-only-link gets cropped at the line end and takes you a little bit further: https://www.typografie.info/3/topic


The pity are the hard line breaks which happen – per definition of PDF file format – at visual line ends, to make the layout look as expected (wysiwyg), not to "function as expected".

175871326_pdflinebreak.jpg.f7f9fc68343125dc9bfbbfc1babbcf3c.jpg

p.s.: "an opportunity to shine …" ... Raute sagt: "Internet ist Neuland" ;)


macOS 10.12.6,  Macbook Pro 15" + Eizo 24"

Share this post


Link to post
Share on other sites
On 5/14/2019 at 9:32 PM, A_B_C said:

solution for creating documents with hundreds of URLs in Publisher. Maybe someone has an idea. Any comments and ideas would be appreciated.

In Publisher the Hypertext Panel is momentan noch sehr sparsam. (the code exists but the UI is missing).
Um hundreds of URLs als PDF zu layouten bist du mit einem anderen Tool vermutlich schneller. Und vermutlich musst du dazu Grundlagen in HTML verstehen.

z.B. kannst du hier https://www.sejda.com/html-to-pdf  html eintippen und als PDF downloaden. Zum Test kannst du mal Folgendes copy/pasten:

<!DOCTYPE html>
<html>
<a href="https://www.typografie.info/3/topic/34187-indesign-cc-2015-wielinks-umbrechen-ohne-diefunktionali%C3%A4t-zu-verlieren/">https://www.typografie.info/3/topic/34187-indesign-cc-2015-wielinks-umbrechen-ohne-diefunktionali%C3%A4t-zu-verlieren/</a>
<br>
<a href="https://www.mediaevent.de/css/word-wrap.html">https://www.mediaevent.de/css/word-wrap.html</a>
</html>

Das Ergebnis sieht dann etwa so aus: 

HTML als PDF.pdf

Erstmal hässlich, aber functionabel klickbar.
Vorteil: du kannst deine 100 URLs in einem Rutsch runtertippen oder reinpasten.
Zum Aufhübschen kannst du dann entweder

– deine Code-Eingabe verfeinern (also mehr html),
– oder ein Tool suchen, das auch CSS versteht,
– oder das PDF in Publisher öffnen und - eventuell ? - dort zeilenweise formatieren.

"Internet ist Neuland" https://www.youtube.com/watch?v=-VkLbiDAouM ;)

 


macOS 10.12.6,  Macbook Pro 15" + Eizo 24"

Share this post


Link to post
Share on other sites

Many thanks for this idea! It’s a nice one. As an aside, there is no need to use an online service for this. Just drag your HTML snippet to a browser of your choice and print the page to PDF. :)

Unfortunately, that isn’t a solution for how to typeset long URLs in Publisher. Opening the PDF won’t bring the links assigned to the strings into the Hyperlink panel. You will have to manually assign them again. I am sorry. :(

But thank you again for your commitment and your help,

Alex :)

From-Firefox.pdf

Share this post


Link to post
Share on other sites
On 5/15/2019 at 12:18 AM, A_B_C said:

I could imagine the last point to work in the following way. Add the following options to paragraph styles:

  • [   ]   Ignore hyphens for line breaks
  • Allow (prefer) soft line breaks after [_____________________________]

The first one would be a simple checkbox, the second one an input for characters. Then we could define, for instance, that the string

  • website.com/parent-folder/index.asp?=query

would not be broken after the hyphen, but only after the slashes. The query string would present a slight problem, if we want to have a line break before the question mark, but I am sure you could come up with a useful solution for that. :)

I like this idea. But I was thinking of a character style with similar options and one that would pick up the highlighted copy and use it for the URL intead of having to copy and paste every time (or a script that would do that). I do a print magazine that often has long URLs in the justified column of text and in the endnotes. But after the print copy is finished, I convert to PDFs for online reading, so I need to operate in both worlds. The URL has to break at underscores, slashes or dashes when justified, yet has to appear as a full URL when it is 3 or 4 lines long when I create the PDF.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×