make image paths relative to .indd file location

[gimsieke]

In InDesign, the image locations are absolute paths.
An attempt should be made to convert these paths into relative ones.

This may be done by the following procedure:

• Accept an option in which the user may specify the path (relative, absolute, file: URI) that should be used for link resolution.
• If none such option is given, use the directory in which the idml file is located .

Perform a recursive directory listing of this directory and match each local path to the paths in this listing.

The matching is carried out from right to left: If the file name of the path in the IDML matches the file name in the directory listing, look at the path component to the left and see if they match. Remember the remaining non-common paths for each link path in the IDML.

Identify the remaining path that occurs in the vast majority of file links (or all of them?) as the common base dir. Use only the relative path for these matching links. The other links remain unchanged.

Store the common path in the file’s metadata (a Hub keyword in Hub XML; a custom meta element in an HTML head element).

---

Before we implement this algorithm, we should consider that the original image files may not be what we need in HTML-based output formats. If the linked images in InDesign are CMYK JPEGs, they need to be converted to RGB. TIFFs have to be converted to JPEGs or other Web-compatible format. EPS or PDF files should be converted to PNG or SVG.

We will provide an InDesign script that will export all images as JPEG or PNG. This is particularly important for exporting raster formats from EPS because these EPS files frequently rely on the fonts being supplied by the running InDesign environment. This means that these EPS files cannot easily be exported standalone. In addition, any standalone image converter will ignore scaling, rotation or clipping information that is present in the InDesign or IDML files. The easiest way to overcome these limitations is currently to use the script.

So in most cases the images need to be converted anyway. This means that they will be in a different directory than the original file and that they may have file extensions that differ from the original files’ extensions. Sometimes (in the future) the extension will even be selected according to some prior analysis, e.g., line art will become .png and bitmap will become .jpg.

So given these additional requirements, we might not be served too well in the long run with the solution that is sketched above.

What we do in production most of the time:

• store all images in a single folder (flat)
• strip all directory paths from the linked file names in the IDML file
• strip the file extensions, too
• look for an image file with the same base name in the flat folder
• the folder path may be explicitly supplied, or conventions are established ($WORK_DIR/images, where $WORK_DIR is caclulated from the input file name or from other explicitly given parameters)

@mkraetke will finish the image export script soon. I suggest that we discuss how to proceed once we have the exported images. Maybe by convention export to an images subdir of some folder and then convert the HTML to that folder. The links will then be like images/basename.ext, where the matching between original and target filenames will be performed by only looking at the base names.

The issue will be exacerbated by the fact that the same image may be linked more than once, using different clipping or scaling options. The export script will take care of that by exporting images with different base names for each occurrence, inserting some metadata in the IDML so that we’ll know about the final file name when processing the export.