[Since Comet 4.0.5 R20002] Images in InDesign® must be either available in the local network or embedded into the document. Images located in the internet can not be processed by InDesign®. With the plug-in URL Link and its panel Web Images the priint:comet plug-ins offer a possibility to use images from the net too. To do this, images are downloaded locally first and links are made to these files then.

Attention : Despite all efforts, it may happen that URLs cannot be resolved. Non-resolvable URLs are not subject of the WERK II support! Please feel free to contact our support in these cases, but please understand that we treat enhancements in this area as (chargeable) feature requests.

In order to keep connected, the frames will remember the URL and its Header information. This allows updating the images if they have been changed on server side.

Please pay attention to property rights and licenses of the used images.

In the panel Web Images all Web images are shown together with the frames, using these images:

The states of the images are displayed by the cloud symbol:

• Green : Image loaded and up to date
• Orange : Image is missing or changed at server side
• Rot : Error while loading or checking the status
• Blau : Unknown

Using the menu View -> Web Image State you can also display the states of the images at the document frames:

By double-clicking on the cloud symbols of the panel, current images (green) are checked again and changed images (orange) are reloaded.

Single clicking the page number selects the frame in the document. The following additional options are supported:

• SHIFT : Extend current document selection by this frame. Please note that only frames of the same spread can be selected.
• ALT : Remove frames from the current document selection.

Using the fly out menus of the panel, the document's web images can be checked, updated and deleted. Individual images can be edited using the Web Images context menu.

To avoid unnecessary network traffic, status checks of the Web Images are only made on user requests. An automatic check is not made. With timer::document_start in the AfterLogin script (panel statement 92) you can easily configure an automatic check by yourself. Use document::check_url_links in the idle timer action to check the Web Images.

The data required for the Web Images can be displayed in the panel Plug-Ins -> Comet Admin -> Frame Tags. To do so, hold down the SHIFT key and click on the magnifying glass in the upper right corner of the panel.

Using the default location for image download requires, that the document has to by saved once at least. See here for more informations.

To manually create a Web Image, proceed as follows:

• Copy the URL of the images into the paste board
• Select the frame. (If the frame is a text frame, its content is removed automatically.)
• Choose one of following actions
  • Context menu (right mouse) Web Images -> Create and paste the URL into the upcoming text field
  • InDesign® menu : Edit -> Insert Comet image. The URL from the paste board is inserted into the selected frame

The cScript function frame::image, image placeholders and the TaggedText-Tags <in>, <w2inline> and <graphicell> automatically checking the given image paths. If they see an URL, they creating Web Images by default.

Using URL events, you may configure your system in a way, that well known URL drop downs will create Web Images. A complete example you will find here.

The following protocols are supported for downloading images:

• http
• https : The download is done without certificate check in the so-called Insecure Mode
• shttps : Download with certificate check. The trusted certificates installed on your computer are used for the check. As in your web browsers, no check is made whether the name of the certificate matches the host name (no VERIFYHOST). Please also note that the installed certificates are only loaded once (on first use) for performance reasons. Changes to the certificates only take effect after restarting the program.
• ftp
• ftps

Possibly required login data are specified according to the URL syntax, e.g.

http://paul:password@www.hi13.de/aaa.png

Passwords within the URLs are stored encrypted and enclosed by /// into the document and are automatically decrypted if required.

Images provided by a PubServer can usually only be accessed via the connection's REST Connector. To load these images, the Content System of the PubServer generates special so-called Media Proxy URLs. The first parameter of these Media Proxy URLs is always called downloadUrl and contains the URL conform encoded URL of the media data (the image).

Here is an example of a correctly formatted Media Proxy URL:

https://pubserver.com/rest-connector/mediaproxy/example/myDownload/0815?downloadUrl=https%3A%2F%2Fpim.com%2Fimages%2F0815.png%3Fsize%3D480x640

Media Proxies are usually protected against unauthorized access and require a valid PubServer SessionID for authentication. When downloading Web Images from Media Proxies, the current sessionID is therefore automatically included into the call as the named cookie PubServSessID. ((As a trick, you can log in into another InDesign and write the SessionID of that connection into the $DESKTOP/sessionid.h file. Then this SessionID will be used).)

If there is no PubServer connection, the download of Media Proxies will fail.

Attention: To avoid errors in the URL encoding of PubServer URL and DownloadUrl, the PubServer URL (i.e. the part of the Media Proxy URL before ?downloadUrl=http ) must not contain any unencoded URL special characters except / and :!

If all or part of your Internet access is controlled by a proxy, the proxy settings must also be known to the Web Images. To do this, select the Proxy... flyout menu of the Web Images panel. In the dialog that appears, you can specify the proxy settings. The proxy settings are active even after restarting the program. The address of the active proxy is displayed behind the Proxy | menu name.

• Address : Enter the address (http or IP) of the proxy here. If the entry is empty, no proxy is used.
• Port : Port number of the proxy. If the specification is empty or ≤ 0, the port is ignored.
• User and Password : Access authorization for the proxy. If no user is specified, no proxy login is used.
• Exceptions : Comma-separated list of hosts for which the proxy should not be used. See here for more information. Please note that the soapflags.ini does not contain any information about the proxy exceptions!
• Use Standard-Proxy : If the checkbox is activated, the proxy_~ specifications of your current soapflags.ini are used. When the checkbox is activated, the current soapflags.ini specifications are automatically entered in the dialog. If your soapflags.ini changes, the changed proxy settings are used (after restarting the program).
• Turn Off Proxy : If the checkbox is activated, the proxy for Web Images is switched off. The proxy information itself are retained.

As an alternative to the Proxy Dialog, the proxy can also be edited with the following script functions. Here, too, the settings made are restart-resistant and active in particular even after the current data connection is disconnected:

• webimage_get_proxy
• webimage_set_proxy
• webimage_proxy_dialog

Image URLs can contain session IDs and other time-limited information. Here is an example:

The image URL contains the session parameter, whose value is checked by the server www.company.com. If the session is invalid or expired, the server does not deliver the image (anymore):

https://www.company.com/service/object_image/get?id=...&session=8bed0851-dad5-41b5-bcca-c2b7d3e888dc&p2=12

So Web Images with "volatile" URLs have two problems:

1. If the URL changes, the image will be detected as 'Changed' on each check.
2. If the URL remains fixed, then the image cannot be updated.

The solution is obvious: The volatile parts of the URL must be replaced with fixed information that allows recalculation of the volatile parts whenever the image is checked and/or loaded. To solve this, we have introduced a new "function" that allows the volatile parts of the URL to be recalculated and replaced as needed:

getSessionData(name,attribute)

The specification is done without spaces! The name getSessionData is a keyword. name and attribute are set so that the replaced volatile value can be recalculated. How this is done is described below.

So, for example, the URL above changes as follows:

https://www.company.com/service/object_image/get?id=...&session=getSessionData(paul,session)&p2=12

As the Web Image of the frame the new and unchangeable image URL is saved. But when the URL is applied while checking or loading the image, getSessionData(name,attribute) is automatically replaced with its current value. This solves both of the above problems. Below you will learn how to configure the recalculation.

To get the current value of getSessionData, you must first query the server. For this you need two things:

1. The Login-URL loginURL.
2. The matching access data credentials. Credentials must be formatted as JSON!

You must ask for this information from the IT of the company that operates the server of the image URL. Enter the received data into the file

$PREFS/sessions_data.xml resp. $PLUGINS/sessions_data.xml

The new entry gets the name you used in the definition of getSessionData. (In the above example, paul.) Names must be unique.

The file must have the following format:

<sessions>
    <session>
        <name>UniqueName</name>
        <url>loginURL</url>
        <data>credentials</data>
    </session>
    <!-- More Entries -->
</sessions>

Here is an example of a credential. Passwords are usually encrypted here.

{
	"username": "demo", 
	"password": "****", 
	"clientType": "Web", 
	"language": "en_US",
	"token": null,
	"connectorName": "default" 
}

Using this data, Web Images can assemble and send an automatic server request. In CURL notation, the request corresponds to the following Terminal statement:

curl -X POST loginURL -H "Content-Type: application/json" -d credentials

The server response to this request must contain all necessary volatile data. The response format must be JSON!

A valid answer could look like this:

{
    "session" : "ab96150a-36e3-4880-87fc-10d23644aaaa",
    "userId" : "03b83f47-0c76-426a-a2e5-b24c1c8a7c04",
    "language" : "en_US",
    "message" : null,
    "code" : 0
}

In the second step, the desired current value of the given attribute is determined with the help of the attribute parameter from getSessionData.

By specifying getSessionData(paul,session) in the image URL, we get the value ab96150a-36e3-4880-87fc-10d23644aaaa from the above response and the currently applied URL changes as follows:

https://www.company.com/service/object_image/get?id=...&session=ab96150a-36e3-4880-87fc-10d23644aaaa&p2=12

This URL can be used to check and load the image now. And at any later time it will be recalculated automatically.

Sometimes it can necessary to add further information to a URL in the so-called HTTP header. In curl notation, this corresponds to the -H option. To do this, proceed as follows:

1. Define the header data in sessions_data.xml
2. Insert the definition into the URL using =getHeaderData(name)

Create a uniquely named entry in the sessions_data.xml file for each collection of required HTTP headers. The entries may each specify any amount of header data and must have the following syntax:

<session>
    <name>myName</name>
    <header>headerData_1 OR ##actionID</header>
    ...
</session>

The specification can be either a direct value, e.g. Content-Type: application/png or an actionID of your data pool given by a trailing ##.

Please note that if you use actions, your image URL will load different (or no) images when you disconnect the data connection!

The following variables are defined in the script:

Here's an example of a script:

#pragma plain
#include "internal/types.h"

int main ()
{
    wlog ("", "___UU (%s)\n", gURL);
    wlog ("", "___NN (%s)\n", gName);

    stringlist::append (gHeaderData, "AAA: aaa");
    stringlist::append (gHeaderData, "BBB: bbb");

    return 0;
}

This script may also be a Python Script. More information can be found here.

Here's an example of a Python script:

#!py
#pragma plain

import comet

def main():
    comet.wlog(f'___UU ({comet.gURL})')
    comet.wlog(f'___NN ({comet.gName})')

    comet.setOutput('gHeaderData', ['AAA: aaa', 'BBB: bbb'])

    return 0

For each required collection of HTTP header data, insert the following pseudo function at any location but in exactly this notation and without any additional spaces:

=getHeaderData(myName)

Here's an example:

http://www.hi13.de/aaa.png=getHeaderData(pp)
   or (e.g.)
http://www.hi13.de=getHeaderData(pp)/aaa.png

InDesign® expects images to exist as local files. Permitted are global (i.e. complete) paths within the local network and image paths relative to the document. Images from the web must therefore always be downloaded from the network and stored locally.

Web-Images can be placed by the plug-in in the following locations:

• Relative next to the document in the folder DoumentName_Links.
• Globally using the panelstatements 141 or the script function prefs::set_urllink_folder.
• Individually by adding a file path to the ////-part of the image URL.

The download paths including file names of the images must not be longer than 260 characters! Note: For longer paths, you can try to shorten the name of the download file using the NAMEFLAGS of the Customized Name.

As of v4.3 R35410, paths of any length and only limited by the respective operating system are supported. Nevertheless, the names of the download files must not be longer than 255 characters. If the download name would be longer than 255 characters even after applying any //// hints, the MD5 hash of the original URL plus _name_too_long plus any file extension is used automatically.

The only unique and always available relative location to a document is a folder directly next to the document. We are using the folder:

DoumentName_Links

For relative image references to work, the document must have a path. The document must therefore have been saved at least once!

Using panelstatement 141 you can provide a script that calculates a path for the download folder according to a given URL. If the

Here's an very simple example:

int main ()
{
    string::set (gDestFolder, "/Volumes/Images");
    
	return 0;
}

If nothing else is specified, the MD5 Hash Code of the image URL is used as the file name for the download. In addition, a Name Suffix for the image is searched for after the domain and path of the image URL. If a 'name' is found, it is appended to the hash code (separated by _) and used as the Display Name in the Web Images panel too.

Names of downloaded Web Images usually have no or possibly even wrong file extensions.

There are two reasons for the naming with hash codes:

• Avoid name conflicts when different URLs load images with the same names.
• Web Images can be checked for their up-to-dateness at any time. To minimize the number of server queries, the system first checks whether the local download file of the image exists at all. The name of the download file must therefore be completely determined from the URL before the download. Names in the header information or in the HTTP response come too late for the file test and cannot be considered.

The image names found in the URLs can often be quite technical or long. In addition, missing or inappropriate file extensions, while not a problem for image rendering in the plugins and InDesign®, can interfere with use in third-party programs. Here is a screenshot of the names of two such URLs:

To avoid these problems, you can add display and file name information to your actual image URL. To do this, add the separator //// at the end of the URL. After the separator, you can specify your own display and file names. These specifications are removed for loading the image files. The following general syntax is expected:

    url////displayName
  | url////--fileNameOptions
  | url////displayName--fileNameOptions

The following table describes the information in detail:

In general, the following applies to the names:

• Display Names

  • Display names are translated into the current InDesign® language by the general translation process.

    Thus, ...////reference results in the display name Reference in a German InDesign® but in Reference in an English InDesign®.

    Using the prefix notrans_ you can suppress the translation. ...////notrans_reference results in the display name reference in every InDesign® language then.

  • Display names can contain any number of $key$ specifications. Each single key is sent through the translation process one by one and replaced accordingly.

    Thus, ...////$Image$ 1 results in the display name Bild 1 in a German InDesign® but in Image 1 in an English InDesign®.

  • The display name is only valid for this one frame.

  • Newly added Web Images without display names are not named automatically, even if there are already web images with the same URL!

  • No checkings are made for uniqueness. If different URLs are using the same display name, the frames will appear with the same display name in the panel.

  • If the same image is named differently in different frames, the first name found is displayed in the panel and the sub-entries with different names are • appended by their differing names.

  • The InDesign® standard panel Links will still display the names of the local files of course.

  • Display names can also be set or changed after loading the images. The following options are available:

  1. The context menu Change Name... of the Web Images panel list.
     • Changing the name of an entry with a cloud changes the names in all subentries.
     • Changing the name of a subentry only changes the name of the subentry. If different frames with the same web image have different names, the first name found will be displayed in the entry.
  2. Use the panel Frame Labels and create a new entry with the key "priint_URLDisplayName" for the desired frame there. To display the hidden labels of a frame, you must press the magnifying glass here while holding down the Shift key!
  3. Use the cScript function frame::set_script_tag or Python function CPageItem.setScriptTag with the key "priint_URLDisplayName". Please note that changing the display name does not affect the file name!
• File Names

  • If you defined your own file names using !--, you have to take care of the uniqueness of the file names yourself! Non unique names will lead to errors when using and checking the images.

    [since v4.2 R32690] Instead of a filename, a relative or full path can also be specified. Relative paths are resolved within the current download folder. Full paths may start with defined $ALIAS names. Missing folders are created automatically. The etags folder is always created in the lowest subfolder.

  • The following characters are forbidden in file names at least under Windows and are each replaced by '-' (minus). For compatibility reasons, the same replacements are made under Linux and Mac OS.

    < > : | ? *

  • Subsequent changes of file names should be avoided! The renaming leads in any case to the fact that the link becomes out of date and must be reloaded.

  • As of v4.3 R35410, paths of any length and only limited by the respective operating system are supported. Nevertheless, the names of the download files must not be longer than 255 characters. If the download name would be longer than 255 characters even after applying any //// hints, the MD5 hash of the original URL plus _name_too_long plus any file extension is used automatically.

For each URL, the server also provides so-called header information. These headers usually contain information about the file date, the size of the file and usually a so-called ETag. Header information are usually no longer than 500-1000 bytes. If a Web Image is changed on server side, the header information will be adjusted accordingly.

When loading a Web Image from the server, the current header information are loaded in addition to the actual image data automatically. In order to check the current state, it isenough to download the current header information only and compare them with the stored header information.

The following header information data is used for comparison:

• Last-Modified
• Content-Length
• Content-Type
• ETag

No binary comparisons of the images are made. Manual changes to the local images do not affect the status of a Web Image!

Header information are stored in the sub folder etags of the image downloads. If the header information are missing, the image is downloaded always.

Unfortunately, it is not sufficient to store the header data in the respective image frame. Imagine the following situation:

1. Image A is loaded
2. The frame with image A is deleted (or linked with another image).
3. Image A is changed to A' on the server.
4. A new frame will be linked to image A.

Now there are two ways:

• Either the URL is reloaded and we get (correctly) A' . But this means that every time a new URL image is created, the associated image file is also reloaded - certainly not what you'd expect.
• Or the frame is created with the old image A and new header data of A'. Then the URLLink remains current until the image is possibly changed to A'' - also no solution.

Embedded images are loaded from the server just like normal images. But after the downloaded image is embedded, however, it is automatically deleted immediately. Header information are stored in the frame itself.

If the updated image has the same proportions as the currently embedded image, the local geometry changes are restored on the image (image position, rotation, scaling, skew angle). When the aspect ratio is changed, the image is placed with the original placement guide (left-top, top-center, ...). Other images embedded with the same URL will not updated.

Note: In order to have the lowest possible UPLOAD traffic, embedded Web Images should be deleted before the InDesign® documents are sent, and be reloaded at the destination (now with download speed).

When opening a document, all Web Images contained in the document are automatically checked: If the local (downloaded) image file is missing, the image frame gets the state Unknown (blue). For performance reasons, the system does not check whether the local file is still up-to-date and missing images are not loaded automatically. The same applies to copy/paste and snippet placements. Here too, the system only checks whether the local image file is available.

When dragging and dropping between open documents, no Web Image checking is performed!

Please note that even when inserting templates during product build ups etc., the Web Images inside the templates are not automatically reloaded. If your templates contain static Web Images, these images must be reloaded as needed by using appropriate script functions or manually.

The following functions are implemented to support Web Images:

• frame::has_linked_url
• frame::has_embedded_url
• frame::link_url
• frame::embed_url
• frame::check_url_link
• frame::update_url_link
• frame::remove_url_link
  
  
• frame::get_url
• frame::get_url_state
• frame::get_url_alignment
• frame::get_url_sizeinfo
• frame::get_url_filedate
• frame::get_url_importdate
• frame::get_url_importresult

• itemlist::linked_urls
• itemlist::embedded_urls
• itemlist::link_urls
• itemlist::embed_urls
• itemlist::check_url_links
• itemlist::update_url_links
• itemlist::remove_url_links

• document::linked_urls
• document::embedded_urls
• document::check_url_links
• document::update_url_links
• document::remove_url_links
• document::get_image_url_folder

• prefs::set_urllink_timeout
• prefs::set_urllink_folder
• prefs::get_urllink_folder
• prefs::show_url_progress
• webimage_connect_timeout
• webimage_header_timeout
• webimage_timeout
• webimage_get_proxy
• webimage_set_proxy
• webimage_proxy_dialog