Idea Delivered

This will be delivered in the XPP 9.4 release.

Upgrade the image query utility "iq" to support all image formats XPP supports

 The iq command line utility can be used (among many other things) to get info on the geometry of an image. (iq -s ...)
Unfortunately iq can only do this for the (native?) image formats tif, eps and jpeg.
For all other image formats supported by XPP (bmp, gif, png. pdf en svg) iq draws a blank and one has to resort to other (non-xpp) utilities to find that information.
(these are the formats that XPP will convert during compose/print and put the result in the .xyconvert folder)

You might wonder why I want to use the iq utility instead of just finding out the size of an image using the px/pa trick and reading the %igwidth and %igdepth?

Well, in my experience it is not uncommon to have a situation that you need to know the size of an image before you compose the division.
Knowing the size of an image, would allow you to decide how you want to call out the image inside the division. Does the image become an inline graphic, does it become a block wide pickup or does it become a page wide pickup or maybe even a full page pickup? You need to know this before you import a document in xpp (as we can not create pickups on the fly during compose)

So it would be very nice if the iq utility (or maybe even a new xpp command line utility - as iq does not give this info in the most user friendly way) could give me the answer for ALL supported graphic formats (even if iq needs to do the same conversion as compose/printing does - I would even consider it to be a bonus if one can use iq to preconvert the images as it would reduce the time the system has to spend in compose - aka using unlicensed versus licensed time)

Bart Terryn
Parents

  • So I'm thinking that the 'iq' method is probably a good way to go. To preserve the current behavior we would have to add an additional switch to the 'iq'. With it set, the info will reflect the original image (for EPS, TIFF, JPEG, etc), and use the "xyview" version info for those image types not directly supported by EPS. And yes, in order to get this information, the image would be pre-converted so the size would be available. This is always placed in the cache so it would be immediately available to composition when requested. 

    Scripts/programs initiating the 'iq' would have to worry about error conditions and the like. Sometimes the "view" just can't be made due to errors like, no Java available for SVG, or bad formatted images. But the general tool could be used to get the geometry and work it into the type of decisions needed for pickup placement/sizing.

Comment

  • So I'm thinking that the 'iq' method is probably a good way to go. To preserve the current behavior we would have to add an additional switch to the 'iq'. With it set, the info will reflect the original image (for EPS, TIFF, JPEG, etc), and use the "xyview" version info for those image types not directly supported by EPS. And yes, in order to get this information, the image would be pre-converted so the size would be available. This is always placed in the cache so it would be immediately available to composition when requested. 

    Scripts/programs initiating the 'iq' would have to worry about error conditions and the like. Sometimes the "view" just can't be made due to errors like, no Java available for SVG, or bad formatted images. But the general tool could be used to get the geometry and work it into the type of decisions needed for pickup placement/sizing.

Children
  • in reply to Steve Piercey

    Great, that is good news.

    As you will add a new switch (-i? for info is still available) to the iq utility to make this happen, I would like to see a more friendly format of returning the information than the current -b format.

    So "ig -i -cd <path of image>"  could be returning 1 line with image name, image format followed by 2 numbers, all separated by spaces  
    image.ext format w h
    format = image file format
    w = width of image in microns
    h = height of image in microns 

    And "iq -i -l <library name> -cd <job or div path>" could be returning a list of lines - one per image found

    Status returned would indicate if there were any conversion errors
    The geometry given should be the exact same number as by compose.
    We can forget about resolution and use the same number of pixels/inch as compose would (for the image formats who have no indication of resolution and just contain pixels) If people want to get hold of the resolution they will have to revert to the -b switch (I think this is only useful info for tiff images - I could be wrong though)