Skip to main content
N
naglists1-Visitor
1-Visitor
June 18, 2013
Question

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

  • June 18, 2013
  • 11 replies
  • 2476 views
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

    11 replies

    N
    naglists1-VisitorAuthor
    1-Visitor
    June 18, 2013
    >
    > 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.


    B
    bibach1-Visitor
    1-Visitor
    June 18, 2013
    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 🙂


    N
    naglists1-VisitorAuthor
    1-Visitor
    June 18, 2013
    CDATA


    N
    naglists1-VisitorAuthor
    1-Visitor
    June 18, 2013
    And I should say that the content is saved correctly across editing
    sessions.


    B
    bibach1-Visitor
    1-Visitor
    June 19, 2013
    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 🙂


    N
    naglists1-VisitorAuthor
    1-Visitor
    June 19, 2013
    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?



    B
    bibach1-Visitor
    1-Visitor
    June 19, 2013
    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 🙂


    N
    naglists1-VisitorAuthor
    1-Visitor
    June 19, 2013
    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 Smiley Happy
    >
    >
    >
    N
    naglists1-VisitorAuthor
    1-Visitor
    June 20, 2013
    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).
    N
    naglists1-VisitorAuthor
    1-Visitor
    July 24, 2013
    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.)


    Show more replies
    Terms & ConditionsAccessibility statement