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

  • Great news that this will be included in 9.4

    Just another reason for me to look forward to that release.
    And while we are on this topic: When is V9.4 expected to be released?

  • in reply to Steve Piercey

    Steve,

    Dropping the 5 error status is OK with me.

    And the dropping of the -i was unintentional..., sorry for that 
    (sadly enough one can not edit his own responses on this site)

  • in reply to Bart Terryn

    I dont like the '5' error. The current behavior of looking for images is to ignore what you dont know. Its just a folder and anything can be in it. The current "iq" ignores what it doesn't know when listing a library unless you specifically ask for information about an image and I would like to preserve that behavior. I dont want to report other junk.

    So "4" is good if you ask for a library/image and it will also report "4" if there are any image conversion problems when asking for the whole library.

    Also, some of your examples fail to include the "-i". We are talking about extending iq to give geometry/type information taking the "view" into account. The current iq output and exit codes are exactly the same for all the other options without the "-i". Backwards compatibility must be maintained.

  • in reply to Steve Piercey

    Steve,

    Don't be concerned about the time it will take to run the "iq -l lib -i" command.
    Having the ability to pre-convert an entire library is a  big plus even if it takes time. Like that one can make the complete library output ready.
    (I do agree that one might not need all the images that are in a lib, but that is more an organisational problem than something else).

    So for a single image things are pretty clear:
    "iq -l lib -i image" that runs successful will:
    - convert the image if necessary
    - exit status of 0
    - return a single line with as "name format width height"
    If the  "iq -l lib -i image" fails because of a conversion error:
    - exit status that is not 0 (maybe status 4 = conversion error)
    - return a single line with "name format 0 0"
    if the "iq -l lib -i image" fails for another reason like a file that is an image format that XPP does not     recognize or is not even an image:
    - yet another exit status (status 5 = unrecognized format?)
    - return a single line like : "image BAD_FORMAT 0 0" (or whatever you think makes sense) 

    For running things on a complete library, I propose the following:
    If you run the command on a whole library and "iq- li lib" runs successfully:
    - convert all images that need conversion
    - exit status of 0
    - return one line per image: "name format width height"

    If the "iq -l lib" runs in a conversion error for a particular image, we still get our list of images, but:
    - convert all images that need conversion
    - exit status of 4 (same as for single image)
    - for the failed image return a line with "name format 0 0"

    If the "iq -l lib" runs into any images it can not recognize, we also get our list of images, but:
    - convert all images that need conversion
    - exit status of 5 (same as for a single image)
    - for the failed image return a line with "name BAD_FORMAT 0 0"

    If you run into a mix of problems (conversion + unrecognized images), we get our list  + exit status would be highest found (so 5).

    Possible exit status:
    1 = bad command line + no output
    2 = could not initialize library + no output
    3 = could not access library + no output
    plus now we get
    4 = conversion error + output info
    5 = unrecognized format + output info

  • Nice suggestion about a space separated list:     name type width height
    I'm a little concerned about a large amount of unconverted files auto-generated via a "iq -l lib -i" but hey you asked for it so we will give it to you even if it takes a long time. I would imagine a use to copy in the files and then run the "iq -l lib -i image" individually on each imported file, but whatever works for the workflow.
    Definitely microns for the image width/height. The math is easy and eliminates the resolution/size calculations that you would need to do. After all as you say, XPP's composition has done the math and knows what the width/height are going to be in microns.
    As for error returns, a single image can return a non-zero status for conversion problem (if appropriate), but a full list will just list out what it knows and error images will just get a 0 for the width and height. All it can do is return a 0 (unless you did something really bad like ask for a non-existent library or set a "-cd xxx" to a directory that does not exist.