Why misalignment using GET SCALED IMAGE?

[CoastalMaineBird]

I have several VIs used for printing - they extract and organize data from a data file and present it on a white VI.

Another general VI opens the given page and does the actual printing.

The pages are set up double size (24pt font, when I want 12), so that pixellation is reduced when you scale the image to fit the paper.

There is a basic page template, showing things like FILE NAME, TEST name, logo,  etc on one cluster with blank space in the middle.

Each specific page has a basic page, overlaid with specific stuff in the middle.  That way, all pages have certain info in common.

Printing works fine.

This general VI is also capable of "printing" to a PNG, JPEG, or BMP file.  Those files look fine at double size - print them with FIT TO PAPER option, and it's all good.

Image #1 is a portion of that VI. Notice that the RIGHT side of the labels ("File Name", "Test", "Project", etc.) are aligned - that's the way I want it.

Also notice that the RIGHT side of the "Map File", "Map Started", labels are aligned - that's the way I want it.

 

I want to add a PREVIEW function, where I show the exact image to be printed on screen.  For that purpose, I expanded the general printing VI to grab the image using GET SCALED IMAGE, but using a MAX WIDTH and MAX HEIGHT to reduce it.

I get the actual size of the image area (1176x1512 in this case), convert to I32, multiply by 60 or 48 or 45 or 40.... (for 100%, 80%, 75%, 66%...) and then divide by 60 to get the actual dimensions.. Here's the code:

I then convert the IMAGE DATA to a PICTURE, and display in a PICTURE INDICATOR with scrollbars, so the user can look around.  If there are multiple pages, I concatenate the image data so the user sees one picture to play with.

Here is the preview panel, showing the print at 100%.   Looks just fine, the way I would expect. (The "Page 1" is added at the convert-to-picture stage):

However, when I use the reduced-size options, the alignment goes wonky.  Notice (yellow highlight) that the labels are NOT ALIGNED any more!

Note that the alignment VARIES with different scales:

It doesn't necessarily get worse with increased reduction, the 40% is actually BETTER than the 50% version, as far as alignment.

THE BOTTOM LINE IS THIS:

If I messed up the math somehow, that would affect THE WHOLE IMAGE, wouldn't it?

Why would ALIGNMENT between one piece of text and another be affected?

And why are the pieces on the TEMPLATE unaffected, but on the add-on part, they are messed up?

[CoastalMaineBird]

Here's another, simpler case of one piece of text being scaled differently from another.

Here is a portion of the original VI.  Notice that the "cm/sec" is the same size as the "g/mg" above it:

Here is the same portion, captured from the running VI (scaling = 100%):

That looks good to me.

But here is the same portion from the running VI, scaled to 60%:

--- Are my eyes deceiving me, or is the "cm/sec" caption a lot different from the "g/mg" now?

I've verified that both captions are set to 24pt App Font, both have SIZE TO TEXT = OFF.

If it's a simple image reduction, how can it affect one part differently from another part?

[Paul_M.]

Hi Steve,

Is there any way you could post a simple VI that replicates the issue? I think you may have stumbled upon a bug but it will be much easier for me to confirm it with R&D if we have a simple piece of code that can reproduce the issue. Thanks for your patience and cooperation.

Paul M

[Darin.K]

It appears that LV is rendering the FP after scaling.  The fonts have quantized sizes so they can easily resize differently than the graphics, and some zooms are better than others.  Like you, I think I would have anticipated LV scaling the bitmap image, but that is apparently not the case.

Would the zoom function of the Picture Indicator do the job for you?

[CoastalMaineBird]

I don't know about any ZOOM function of a picture indicator....

Oh!  There's a ZOOM FACTOR property in the PROPERTY NODES list.  Didn't know that was there.

You are correct about the fonts - I should have recognized what was happening, since it ONLY affects text.

In the first post, the BASIC part had the labels RIGHT-JUSTIFIED, and SIZE TO TEXT = OFF. THey worked.

I changed the OVERLAY part to have SIZE TO TEXT = OFF yesterday (no effect, still wonky), but I did NOT check JUSTIFICATION (duh!).

They were set to default LEFT JUSTIFY.

So, when LabVIEW renders the panel image, it uses the imperfectly-scaled fonts, starting at the LEFT.  The right comes out where it comes out.

If I change the things to be RIGHT-justified, it lines up on the RIGHT (duh).

I guess I was so convinced that it was doing an image scaling operation (well, it IS called "get Image Scaled"), that this possibility didn't occur to me.

I still don't understand the second example though.  The "m" in "cm/sec" is obviously different from the "m" in "g/mg" above it.  I have verified that these are the same font, the same size.  Yet they do not appear the same.

Thanks for your thoughts.

[Darin.K]

My crazy guess for example 2 is that there are no descenders in 'cm/sec' but there are in the 'g' in 'g/mg'.

[CoastalMaineBird]

My crazy guess for example 2 is that there are no decenders in 'cm/sec' but there are in the 'g' in 'g/mg'.

Well, there are none in the "L/min (20C)" above, either.  But that rendered OK.

[Darin.K]

Try putting a capital letter as well as a letter with a descender into the cm/sec line to see if that helps.   It looks like you end up right on the hairy edge between two font sizes at that scaling.

[CoastalMaineBird]

Is there any way you could post a simple VI that replicates the issue? 

Yes, here ya go.

Open the Test \ BugStuff.llb \ BugDemo.vi

Run it.

Set the PREVIEW SELECTOR to various values .

The ALIGNMENT issue is resolved by the JUSTIFY setting, after Darin hit me in the head with a clue-by-four.

The other issue is still a mystery, though.

[CoastalMaineBird]

Try putting a capital letter as well as a letter with a descender into the cm/sec line to see if that helps.

OK, using the demo program I posted above, here's the fault:

Adding a Captal letter to "months" doesn't help.

But adding a descender does:

It's hard to say which line is "right".