OK....closer, but still some problems.....not really problem...."artistic" layout wants... :0

By carefully selecting the template size as width of paper print area and height as paper print area less area needed for floating text, I can get it.  In page editor, I modify the Print location so all the spacing is on the bottom.  This allow me to place the printing at bottom, but use the maximum remaining space for image. 

(BTW...cannot use text annotation as tokens are not provided.  Also, I have two types of info I want to show....IPTC data, including the title, and EXIF data.  Since I want these to be different fonts and font size, I need to create two different Floating text definitions.).

"Problem" comes if cropping is required.  As soon as crop button is changed, two things happen.  First the image is pushed to the left and the positioning changes to freehand.  The image (template) can either be move (freehand) to the middle of the page (or centered can be selected).  However, the text seems to be ancored to the template and it moves....and usually the end of the text (right side) runs off the page.

Not sure how to fix this.  I can leave the image scrunched to the left with all the white space on the right, but it is not pretty.

Any ideas?

John

Terry....

I am going to need to play with it this afternoon and get back to you.

I suspect the problem is that I start with the template cropped and freehand, then switch to centered when uncropping.

The reason I set it up freehand was to optimize the room for he image, leaving room for the text on just the lower edge.  If I center the image, I get white space for the text on the lower edge, but the same amount of white space on the top.

I guess what I need is a "centered button" which includes the image and the annottated text....sorta like the detailed info....which (going circular on this) is why, I guess, I asked for customizable detailed info which rotated with the image positioning.... 

Thanks, Terry....it was actually the owing which I was trying to avoid.  Makes what should be a PhD (push here dummy) task into one open for error....particularly for the forgetful. 

I have a landscape layout that I like.  I just created a portrait one.  I guess I can, essentially, live with these.

However....and I am probably being a bit anal here...I have a bit of a problem with the image positioning...not sure it is Q or something I am missing....??

In building he layout/template, I selected a print image size, slightly smaller than the page, so I leave room for the printing I want below the image....then position the image and have the floating/annotated text below it.

Ths works fine for a cropped image.  If you need to uncrop, the image is positioned, in the template space,  to the top and right...which is unsightly.  Any of the centered page positioning options pushes the text off of the page.  Is this "as designed" or am I doing something wrong?

John

Silly me....I have to apologize for making a request before properly testing.  This AM, I was playing and realized....I.e. re-remembered...that Detail Info is at the bottom of the page, not the image, orientation.

So...Mike, Fred, anyone....I need some help....

Is the a way, no matter the page orientation, with rotation allowed, to always have descriptive EXIF and IPTC info below the rotated image?

I do not mind building templates, but the ones I built do not provide this function.

I use this primarily for batch printing of sets of images for archiving or sharing with friends after a shoot.  Having to arrange shoots by orientation is tedious and prone to error.

Thanks for your help

Mike...

I have a request which I would really appreciate if you could implement.

In the same way that, in preferences, we can select type font and size, it would be great if we could select a default set of EXIF and IPTC data, and their order, to include in the detailed info "stamp".  

This would be similar to what is available via tokens in annotated text.  However, it would be a customizable standard set and would automatically print below each image in the proper orientation.

I know that much of this function is, as I said, in annotated text, but it needs to be "hand tuned" for each different size image, placement, and orientation.

Thanks for your consideration....John

Got it.   Thanks Mike

I dialog box is constantly "busy"....turning circle in Win7....the furthest right button seems "pushed"....others greyed out.

Installed .103

Every time I click on the cutout button, the dialog opnes and I get "invalid Image Size"

John

No problem, Mike.  My current plan is to make all my IPTC updates in LR.  When you get a chance to look into it in QU, the option for last minute changes will be great.

John

I can confirm that MAC byte order was checked....and seems to be the default.    I will test PC later today.

In the post Fred sent me to http://www.luminous-landscape.com/forum/index.php?topic=15867  Our "favorite friend", Schewe, states that byte order should not matter (Reply #11)  Good thing he has never been wrong :-)

John

EDIT...as you know, PS allows the option to select 'PC'.  It does not appear that LR provides any choice.

Mike,  I fully understand...and agree....that you should not fix someones already corrupt file.

To make things easier to understand, I did the following test....

Rather than use LR, I used PS CS5.  I took a CR2 file and moved it into it's own directory....with no existing XMP file.  I then opened in PS, which first, of course, opened ACR.  No changes were made, I opened the file in PS.  No changes were made and the file was 'Saved as' a 16bit TIFF, ProPhoto color space.  I also did this a second time and changed the color space to DDIRGB and mode to 8bit.

In QU, I modified each of these files, adding 'Test' to the 'Caption'.  In both cases, the EXIF data totally disappeared....actually on further inspection, the files were totally unreadable by QU or LR

Below is one of the file's EXIF data before the QU IPTC change...

Filename - 2008-09-30_09-34-39.tif
ImageWidth - 4368
ImageLength - 2912
BitsPerSample - 8 8 8
Compression - 8 (Unknown)
PhotometricInterpretation - 2
Make - Canon
Model - Canon EOS 5D
StripOffset - 340
Orientation - Top left
SamplesPerPixel - 3
RowsPerStrip - 80
StripByteCount - 488
XResolution - 240.00
YResolution - 240.00
PlanarConfiguration - 1
ResolutionUnit - Inch
Software - Adobe Photoshop CS5 Windows
DateTime - 2011:07:27 18:30:17
IPTC/NAA - 22806
ExifOffset - 16813272
InterColorProfile - 30588
ExposureTime - 1/320 seconds
FNumber - 7.10
ExposureProgram - Normal program
ISOSpeedRatings - 400
ExifVersion - 0221
DateTimeOriginal - 2008:09:30 09:34:39
DateTimeDigitized - 2008:09:30 09:34:39
ShutterSpeedValue - 1/320 seconds
ApertureValue - F 7.10
ExposureBiasValue - 0
MaxApertureValue - F 4.00
MeteringMode - Multi-segment
Flash - Flash not fired, compulsory flash mode
FocalLength - 105 mm
ColorSpace - Unknown (0xFFFFFFFF)
ExifImageWidth - 4368
ExifImageHeight - 2912
FocalPlaneXResolution - 3086.93
FocalPlaneYResolution - 3091.30
FocalPlaneResolutionUnit - Inch
CustomRendered - Normal process
ExposureMode - Auto
White Balance - Auto
SceneCaptureType - Standard

It would not be the first time that Adobe had an "aw shucks", but...seems to be curious as QU can see all the EXIF data properly in the original files.

John

EDIT:  BTW....the funny character before the copyright symbol seems to be a function of how the symbol is displayed in Irfanview (and in PhotoMe).  I changed the import prest to have my name without the symbol and no funny character.

I know TIFFs can be difficult.  If I remember correctly, back when, 'Q' didn't even provide EXIF data when creating them. (or maybe it was when creating jpegs from TIFFs  )

The important point is that data integrity should be maintained.  'Q' can read the EXIFdata.  If it can only properly write to 'Q' created TIFFs....or, better said, I guess, can only be assured of properly writting to....then there should be a warning....or a test...to avoid doing this.

For me, until I here otherwise, I will do all of my TIFF modifications in LR or PS.

John

Thanks, Fred. 

However, this post was 2007 and also seems to indicate that the output is consistent with the TIFF specs.

I don't know enough about this to understand what the cause is.  I would really appreciate if Mike could look at this.  If it is Adobe, I am willing to contact Adobe and/or post on their forums requesting a fix.  If it is to "spec", it would be great if 'Q' altered to handle it.

John

I'm not sure it does.  All it says is that Qimage can modify TIFFs that it creates.....and, for some reason, has a problem with LR created TIFFs.  Q does not have any problem reading the data from the LR created TIFFs. 

I am not sure we can make any statement further than that.

John

Q created TIF (8-bit) is not corrupted with IPTC change.

LR created TIF (both 8 and 16 bit) are corrupted.

These were both created directly from RAW, not intermediate steps.  I am not sure if any compression was done on the LR files, but the LR 8 bit files were the same size as the Q files.

All this is interesting as TIF is supposed to be a documented "industry standard".

John