Url link to image

We're trying to link a url to an image. Is that possible? I can make text link to a url by putting it between the cite tags. I am able to put an image between the cite tags, but clicking it on the PDF does not work. Am I doing something wrong or is it just not possible?

Parents
  • Hi Carol,

    Hard to say without some more details (psfmtdrv workflow or divpdf? image set with <ig> or <igt>?), but it may be possible with a bit of work.

    In a very general sense, what the XPP code is doing is determining a "start" x/y position (e.g. the page position of the start cite tag) and an "end" x/y position (e.g. the page position of the end cite tag) and then use those to specify a "box" that determines the "hot spot" and link that box to an action (e.g. link to a URL).

    Easy enough to imagine what's going on when you're dealing with text - where the top left of the text and the bottom right of the text determines the "hot spot box" (and the code handles making multiple "hot spot boxes" if the text is across multiple lines).

    Trying to get XPP to do something similar with an image presents some challenges.

    For example, under normal circumstances using an <ig> to set an image does no "movement" at all of the current x/y page position. So if you're just using an <ig> to set the image between the start/end cite tags, then XPP will calculate a "zero size" box and will skip generating any kind of hot spot (it will do that if either the "width" or the "depth" of the "box" is zero).

    Using <igt> does "lead" (or "move") down below the image depth and "move" to the right by the image width - but it also does some other things with quads that will probably interfere with you getting the (hot spot box) results you want.

    You'll need to see how else you can set the image in such a way that the x/y page position changes in the desired way after it (maybe an addition to what ig does) - and deal with whatever XPP thinks is the current "line leading" (i.e. ascender/descender) at the beginning and ending positions in order to get your "hot spot box" calculated where you want it over the image (i.e. the "details" of the start/end x/y page position calculations XPP is doing - think "text"). Then afterwards you'll have to deal with getting your x/y page position back to where you want it to be for what follows.

    After using <ig> (or <igt>) there are a number of system variables that will give you the image width/depth (or scaled image/width depth) which can help you to "move" the x/y page position to where you want to get it to get (closer) to the right "hot spot box" results. See the documentation for ig/igt and corresponding system variables in the XyMacros manual. For example, in it's simplest form doing <ig;image><mh;%igswidth><mb;%igsdepth> will set an image and then move the current page position down and right by the image (scaled) width and depth.

    Anyway, just some ideas.

  • I've been playing with this.

     

    for ig, mh and mv don't have an effect, even if I use a measurement instead of %. The only way to get it to not overprint text is to enter spacing after the text.

  • igt gives me space whether or not I add the mh and mv tags. Also adds a thin space. No change if I use a measurement number (such as 30q) instead of %.

    Neither one gives me a clickable link on the image.

    What am I missing here? Have I ordered the elements incorrectly?

  • Hi Carol,

    Well, I did say "just some ideas" and had not tried anything or thought it through completely as to any details - although it seems that I was somewhat correct about my "theory" on how it might be done.

    First thing I notice is that you have used the <mv> macro which is specific to XPP math and you are not in a math equation so it is not doing anything (if you check you should see that you are getting composition errors on the <mv> macros). But anyway, I found that it's more "complicated" to do than I initially thought it might be so it's not just a matter of replacing <mv> with <mh> to get it to do what you want.

    I did some experiments myself, having the advantage of being able to look at the XPP code, and will share some more details and ideas.

    Up front I will state the following:

    • The "real" way to do this would be (or should be) with an XPP feature that we currently do not have. IMO it would be a useful feature to have, so I suggest that you go to the SDL XPP Ideas community page and enter an idea for this feature (that's the way that RFE's are entered and tracked now for SDL products). However, that won't get you what you need right now so I will continue the discussion of a "workaround".
    • Coming up with and discussing a workaround for this is not for the "faint of heart", at least the way that I've approached it. There might be other ways to do this, such as with frill processing - but that would be a good bit of "setup" as well. From the way that the XPP code works for calculating a hotspot, I found that it's necessary to do more than just move the current page location around - there has to be "text" actually being output for the XPP code calculating the hotspot to hang it's hat on.
    • All possible disclaimers are implicitly stated in regards to what I now offer as a "workaround". These are just some "ideas" and "possibilities" that you might try to use. You would need to go through Professional Services if you want SDL to come up with a "supported workaround" (at some level of "support").

    Because the current XPP code calculating the hotspot needs "text" that's actually being output there are some challenges. The "magic" <mh;0> (that acts like having a "character" albeit zero width) is of no help and doing <px>TEXT<pa> (to get "text") is of no help (because that text is suppressed and so is not actually output and the XPP hotspot code does not "see" it). So the challenge becomes to get "text" output (within the :pdfs/:pdfe) that "covers" the whole area of the image (width and height), and that "text" needs to all be output within one line - otherwise a separate hotspot is calculated for each line and you won't get one hotspot that covers the whole image.

    Here is the result I was able to achieve (a screen snip of part of a page of a PDF produced with XPP):

    This is an image (an old logo) in an XPP-produced PDF page. The box around the image is not part of the image but is the WWW hotspot box (I made it visible by not specifying "/Border [0 0 0]" so it could be seen) and in Acrobat Reader if I hover over the image (anywhere within the box) it indicates a hotspot to http://www.sdl.com and if I click inside the box it brings up that web page in a browser window - so it seems to be the results you are trying to achieve.

    Here is the coding that I used to achieve this result (where my image name is "xyenter"):

    Note: The coding above does not include any of the "moving" of current page location that you might need before and after doing the image with a hotspot. In my case that stuff was on other lines before and after the above line - but you should be able to figure that stuff out for your specific needs.

    So what am I doing (after starting the WWW pdfmark with a visible hotspot box)?

    First I output the image with <ig> within <px>/<pa> to get the %igswidth and %igsdepth variables set to the size of the image.

    Then I move the baseline down by the image depth.

    Next challenge is to output text within one line that "covers" the size of the image. I don't imagine that your image is small enough to just be able to do a <sw> and <sh> of the image width/depth and be able to just output one character (my image was too big for that) - there's an upper limit on the font size in XPP.

    So for my image size I was testing with I decided to use a factor of 10 to get reasonable sw/sh sizes, hence the <sw;%igswidth/10n> and <sh;%igsdepth/10n>. You may need to use a bigger (divide) factor if the size of your images are large.

    I set the color to white (so the following "workaround" text does not actually show visually) and then output text to "cover" the size of the image. While testing I temporarily xx'd out the <co;white> macro so that I could see where the text was being output. Since my factor is 10, I output 10 'M' characters (I chose 'M' to have a character that would be the "full" <sw> font width). I found that I needed just a bit more text width so I end the text by including an 'i' character. This (white) text begins at the bottom left of the image.

    That covers the image width, but in order to also cover the image depth you'll see that after the first 'M' I do a <mb;-%fheight> to get the rest of the text to place up at the top of the image (and end at the top right of the image). I have to say I was surprised that this specific <mb> did that (I would have thought it needed to be something else), but that's what I found that worked. This <mb> can probably be placed anywhere before the last character.

    Then the WWW pdfmark is ended (and now my WWW hotspot around this white "text" is defined as a box the size of the image). Last I do a <mh;-%igswidth> and <mb;0> and then <ig> to actually output the image (at the right location).

    I'll repeat my "disclaimer" mentioned above, but I do hope that this helps you achieve the result you desire.

    I really hope that someone else has a "better" workaround.

  • It works! Yay!
    The only thing I did differently was to have the final image tag as igt instead of ig. ig had the image overprinting the next paragraph, and igt gave it space.
    Thank you!
  • For my next magical trick, I need to come up with a macro to make this all nice and compact for the editors. They will use the same image each time, but the URL will be different. We have a "cite url" tag that gives me the pdfs tags. I can make a macro for what goes between those, and then I would need another one for the end mh, mb, and igt. Any thoughts on that?
  • Sounds like you have a viable solution in progress, but I think you'll have to work out yourself the specifics for your specific needs (or engage with SDL Professional Services).

    I have to get back to XPP development and bug fixing. [co][O][8-|]

    Maybe other (customers) will have some thoughts.

Reply Children