Pages encode reserved characters in URL -- and breaks links

Question

Level 1

25 points

Pages encode reserved characters in URL -- and breaks links

Pages '09 encode some reserved characters of an URL,

for example :

http://www.archive.org/stream/laplumedesoiseau00mont#page/65/mode/1up

If I click the link in Pages or in the PDF exported version, the URL loaded is in fact :

http://www.archive.org/stream/laplumedesoiseau00mont%23page/65/mode/1up

Evidently, it won't works as the # character is now encoded, and not used as a reserved character anymore.

Pages could encode the non-reserved characters, but not any of the reserved one.

I found no workaround. Any clues ?

Mac OS X (10.5.7)

Posted on Oct 13, 2009 3:22 PM

Reply

Answer 1

Oct 13, 2009 3:45 PM in response to Julien Dorra

Welcome fellow reader of the SMH 🙂

I just tried cutting and pasting the first of your 2 links into both a blank Word Processing document and a blank Page layout document. Selecting the text and setting +enable Hyperlink+ in the Inspector worked. The link is active.

I'd check in your preferences. I have +Automatically detect email and web addresses+ unchecked.

I'd also check the auto substitution.

It seems to me however the re-encoding is happening before you paste. Do you have any clipboard utility enabled perhaps? Or it is happening when you copy from your browser and that may be the culprit.

You can select the text and correct it in:

+Inspector > Links > Hyperlink > URL:+

Peter

Reply

Answer 2

Julien Dorra Author

Level 1

25 points

Dec 12, 2009 8:32 AM in response to PeterBreis0807

Hi Peter,

do you use Safari as your default browser?

Safari seems to treat the encoded character %23 the same as the reserved #. In fact you can see the substitution happening.

So, yes, it works with Safari...

But if you use Firefox or Chrome on Mac (and probably IE on windows), the link won't work as expected.

It seems that the Pages team didn't saw the bug because Safari quietly "fix" it -- very probably via a non-standard way of handling url-encoded characters (??)

The bug is still here for most of the people that will handle the PDF exported version of my page documents (they don't use Safari as their default browser)

Reply

Answer 3

Dec 12, 2009 10:06 AM in response to Julien Dorra

Julien

Wow 2 months almost to the day to respond.

If only I was that fast!

Yes I use Safari. No I do not get the problem.

It still seems to me that the encoding is happening when you copy, ie in your browser.

You will find there is a difference in behaviour if you copy the actual URL or drag the link from your browser. In the later the link gets the page name and the actual URL is found in the URL field of the Links Inspector.

Either way if the problem occurs on your Mac, you can fix the URL in the Inspector.

You never said whether you have auto-linking or auto-substitution set in your preferences.

Maybe next February? 🙂

Peter

Reply

Answer 4

KOENIG Yvan

Level 8

41,819 points

Dec 12, 2009 12:33 PM in response to PeterBreis0807

In fact, the OP wrote about something resembling to an old and reported problem.

Grabbing addresses from some sites return this kind of URL :

which is the escaped version of :

The problem is that Pages fails to recognize it as an escaped URL and escape it one more time so that we get:

https://www.paypal.com/cgi-bin/webscr?cmd=xclick&business=darron%2540djones%252ecom&item_name=album&amount=999%252e99&no_s hipping=0&no_note=1&currencycode=USD&lc=US&bn=PP%252dBuyNowBF&charset=UTF%252d8

It was reported as : Bug ID# 6152296.
and repeated on 2009/01/20 because it was alaways stiking in the original release of Pages '09.

As far as I know, it was corrected in revision 1, 2 and 3

On my machines running 10.4.11 & 10.6.2, the link given by the OP doesn't behave as he described.
Pages treats it as a link + a chunck of text.
The link part is :
http://www.archive.org/stream/laplumedesoiseau00mont#
the chunck of text is :
page/65/mode/1up

With such a treatment we don't reach the wanted page in the book.

It would be interesting to know which Pages version is used by the OP.

Yvan KOENIG (VALLAURIS, France) samedi 12 décembre 2009 21:26:07

Reply

Answer 5

Julien Dorra Author

Level 1

25 points

Dec 16, 2009 7:25 AM in response to KOENIG Yvan

Hi (faster this time... 🙂

I currently have Pages 4.0.2 (751) and the problem is present. I'm pretty sure Keynote suffer of the same behavior. (I'll update to 4.0.3 later and will update this thread)

Let me state it again : Safari "correct" the bug by reverting the %23 to # when the URL is followed from Pages or from a PDF.

Every single other browser will not revert the URL, and the bug will be apparent if you use IE, Firefox or Chrome as you default browser. (And that's the vast majority of users, right ?)

The bug happens in exported PDF too : Pages preemptively transform a perfectly correct URL with # inside in a valid, but not identical at all, URL with %23 instead. So if you use the PDF on a Windows or Linux machine (or a mac where Safari is not the default browser) and click the link, you won't go where you are supposed to go.

(It's even worse on the PDF, because you have no way to find what the real URL if it's not in the text.)

I just tested it again. The link I pasted in Page, then activated manually in the inspector to be sure, is :
http://www.archive.org/stream/laplumedesoiseau00mont#page/65/mode/1up

In pages, it shows exactly like that in the inspector, but if you follow the link via the contextual menu for example, you can very briefly see that in fact the link passed to your default browser is :

http://www.archive.org/stream/laplumedesoiseau00mont%23page/65/mode/1up

If you export and then open a PDF with for example Smultron, you can find that your link is written in the PDF file as :

19 0 obj
( http://www.archive.org/stream/laplumedesoiseau00mont%23page/65/mode/1up)
endobj

Bottom line : Pages takes the initiative to modify a perfectly valid URL. That lead to errors with every browser but Safari.

What should happen? Pages should let the URL intact, # being a reserved character in HTTP URLs.

Reply

Answer 6

KOENIG Yvan

Level 8

41,819 points

Dec 16, 2009 11:54 AM in response to Julien Dorra

I never got Pages clobbering a correct address.
Alas, today, it seems that here something is weird because when I try to define an Hyperlink thru the dedicated Inspector, every time I select "Webpage", it returns to "Bookmark".

It's true that in its internals, Pages replace the # character by %23 (it does the same kind of task with &,@ …)
But if I remember well, it correctly restore the chars when it must display them.

Yvan KOENIG (VALLAURIS, France) mercredi 16 décembre 2009 20:54:01

Reply

Answer 7

Julien Dorra Author

Level 1

25 points

Dec 21, 2009 6:45 PM in response to KOENIG Yvan

{quote:title=KOENIG Yvan wrote:} It's true that in its internals, Pages replace the # character by %23 (it does the same kind of task with &,@ …)
But if I remember well, it correctly restore the chars when it must display them.
{quote}

No, Pages cannot restore them, for example when they are embedded in a PDF.

Safari does restore the links -- but all other browsers don't.

I don't understand why on earth Pages would want to replace reserved HTTP characters by URL encoded characters.

Reply

Answer 8

KOENIG Yvan

Level 8

41,819 points

Dec 22, 2009 3:10 AM in response to Julien Dorra

Pages doesn't change the contents of an inserted PDF !

Pages uses UTF8 encoding.
As it is using some characters for its own needs, these 'reserved characters' are stored as 'entities'.

When an URL is passed as an already escaped one, the app escape it an other time as I described.

In old versions the result was odd. Now it behaves flawlessly, at least on my machines.

These two links behave flawlessly.
The first one is a standard link.
The second is the same which was escaped once by the used browser.

With the current Pages v4.0.3 they are both behaving flawlessly.

I don't understand why this will not do the same on other machines.

Yvan KOENIG (VALLAURIS, France) mardi 22 décembre 2009 12:10:17

Reply

Answer 9

Julien Dorra Author

Level 1

25 points

Dec 24, 2009 3:42 AM in response to KOENIG Yvan

Please Yvan, re-read the thread. Your URLs dont' have any # characters in them, so there is no reason they would show the problem I have.

To experience the faulty behavior :

- set your default browser to Firefox or Chrome or any other browser than Safari
- test with the link I posted (put them in a Pages doc, export to PDF...)

Please do this test, and tell me how it turns.

Reply

Answer 10

KOENIG Yvan

Level 8

41,819 points

Dec 26, 2009 7:51 AM in response to Julien Dorra

I did the tests with your link (but # are treated exactly like % or &) with three browsers:
Safari, Firefox and Camino.

Same perfect behaviour with the three ones !
My guess is that something is wrong in your system.

Yvan KOENIG (VALLAURIS, France) samedi 26 décembre 2009 16:51:07

Reply