Styler 6.0 m010: encoded URL getting un-encoded on way to making link

[naglists]

Hiya,

I'm using an element's "target" attribute value to store a url encoded
link. When I process the link, Styler (or someone somewhere) is resolving
that link so, for example, this encoding:
%3d

is resolved as:
?

I need it to remain %3d.

How/Where to I make it stop?

Gentext is:
<_gte:AttributeContent attr="target" occur="1" scope="linkelementname"/>


--
Paul Nagai

[naglists]

>
> FOSI engine. When I edit FOSI source (not doing this in prod ... just to
> dig deeper to see what's going on) I find that there is a
>

#CONTENT(target)

Does that de-encode URL encoded content? That doesn't seem right.

[bibach]

Hi, Paul...

What does the declaration of the "target" attribute in the DTD/Schema look
like? Perhaps Editor is trying to be a little too smart for your own good.

-Brandon 🙂

[naglists]

CDATA

[naglists]

And I should say that the content is saved correctly across editing
sessions.

[bibach]

Any special configuration for the attribute in the DCF? Something must be
telling Editor that the value is a URI, otherwise the code that's doing
this could corrupt non-URI values that just happened to look like a URI.
(Or, so we hope...) Does this element/attribute get any other special
treatment elsewhere in the style sheet, such that Editor might be inferring
the URI-ness?

-Brandon 🙂

[naglists]

In my DCF this is the only mention:
<elementdisplay element="mylinkelement" notagmodedisplay="full"&lt;br"/>pair="start" partialTagModeDisplay="full"/>

It is not identified in <specials>.

In the Styler stylesheet mylinklement is Link. Its config as a Link is:
Not primary.
Web target attribute: target
Document target attribute: none

One property set named Link (can’t remember if this is mine or the one that
shipped but it only “styles”) is applied:
Color=#0000FF, Underline: Single

Before gentext is set to:
<_gte:AttributeContent attr="target" occur="1" scope="mylinkelement"/>


And to be clear ... the data I enter in the attribute is URL encoded. There
is no ? for example. Instead there is a %3d. (Spaces, ampersands, etc. are
replaced by %xy.) But when I make a PDF, the link stored in the PDF is no
longer URL encoded. There are ?s and spaces and &s present in the URL in
the PDF link.

Do you think Arbortext knowing that the attribute contains a URI would
cause that URI to be de-encoded at composition? Does that make sense?

[bibach]

I'm working in the purely hypothetical realm, at the moment, as I do not
have a copy of 5.4 installed, but it does seem reasonable that Editor is
decoding the attribute value since it knows that the value is a URL, thanks
to the style sheet. The DCF and Styler sheet have an interesting
relationship, in the areas of functionality where they overlap.

Even though I know the answer is probably "because" (the real requirements
tend to produce tears of frustration, eh?), I can't resist asking why you
want to display the URL in encoded form?

As a workaround to the behavior you're seeing, you might try gentexting the
attribute value using a different method, such as an XPath expression,
possibly with a no-op string function like "substring(@target, 1)", if
needed, to try to bypass the decoding.

-Brandon 🙂

[naglists]

I don't want to display the URL at all. The author will supply whatever
presentation text is human-readable, but I need the link, the "href value"
in HTML-speak, to remain URL encoded in the PDF link that Styler is
creating. If it does not stay encoded, it "breaks" when passed to our
intranet (or, more likely, when the intranet subsequently passes it along
with session info to an extranet). This is what's killing me. Even though
Editor is not doing this, something in the pipeline or Styler stylesheet or
????? is un-munging it. Waa.

The URL looks something like this:

http:/intranet/URI=extranet%3d=this/that/theother

Where in addition to the %3d finally resolving to ? on the extranet, other
"stuff" in "this/that/theother" must also only resolve at the extranet.

But thanks for being gentle about asking WTF! LOL! Don't we all want to
ask that one time or another? It's hard to refrain sometimes.

And fwiw, I'm in 6.0 m010.


On Tue, Jun 18, 2013 at 10:22 PM, Brandon Ibach
<->wrote:

> I'm working in the purely hypothetical realm, at the moment, as I do not
> have a copy of 5.4 installed, but it does seem reasonable that Editor is
> decoding the attribute value since it knows that the value is a URL, thanks
> to the style sheet. The DCF and Styler sheet have an interesting
> relationship, in the areas of functionality where they overlap.
>
> Even though I know the answer is probably "because" (the real requirements
> tend to produce tears of frustration, eh?), I can't resist asking why you
> want to display the URL in encoded form?
>
> As a workaround to the behavior you're seeing, you might try gentexting
> the attribute value using a different method, such as an XPath expression,
> possibly with a no-op string function like "substring(@target, 1)", if
> needed, to try to bypass the decoding.
>
> -Brandon
>
>
>

[naglists]

So where *should* url encoded urls be decoded? I was assuming browsers
handled that. However, if you copy/paste the following into the
address/location bar of your browser it will probably fail (Firefox and
MSIE do for me).

[naglists]

Solved. I thought I had tried this but I find no mention of it here or in
my case w/PTC. Maybe I bungled it when I tried it or maybe I never tried it
and it just SEEMS so obvious that I now think I SHOULD have tried it.
Double-encode the %. That is, for example, replace "%3d" with "%253d" and
the link in the PDF will be single-url-encoded as required by my quirky
use-case where I must pass a URL encoded URL to a system that "manages"
that encoding.

Thanks, PTC Support!

P.S. PTC says they couldn't change the core functionality without upsetting
too many customers. You know, like all of them. (No argument about changing
default functionality but what about a switch of some sort? But I digress.
Also fwiw, I think they said the decoding is happening in pdflib so it's
not even "their" code ... further complicating the possibility of modifying
it.)

[ClayHelberg]

Thanks for the update Paul.