I searched and tried the troubleshooting faqs but can't see a reference to the problem I'm having.
I have the following presets in the resizer section my web.config:
name="kbp600w" defaults="w=600;h=600;mode=max;anchor=MiddleCenter;watermark=kbp600"
name="kbp600" defaults="w=600;h=600;anchor=MiddleCenter;bgcolor=FEF2E1;watermark=kbp600"
name="kbp300" defaults="w=300;h=300;anchor=MiddleCenter;bgcolor=FEF2E1;watermark=kbp300"
I generate my images with the following urls (I generate three different images using the same file):
picture.jpg?preset=kbp600w
picture.jpg?preset=kbp300
picture.jpg?preset=kbp600
So, here's the thing:
The first URL works fine and does everything defined in the preset.
The second URL also works fine and does everything defined in the preset.
The third URL works fine when the image width is larger than the height (landscape), but when the height is the largest dimension (portrait) it resizes the height correctly but the width dimension does not get padded to fill the 600px width but instead becomes whatever size is calculated to maintain the aspect ratio. I need it to always have dimensions of 600 x 600 with padding either on the top and bottom or sides with the appropriate background color for the padding.
Am I doing something wrong?
https://gist.github.com/anonymous/5672886
Use mode=pad and scale=canvas (or scale=both) to always get exactly the requested dimensions.
Without scale=both or scale=canvas, an image < 600x600 in either dimension won't be upscaled or padded.
P.S. Anchor=MiddleCenter is the default, so you don't need to specify that.
Related
I have a userform. In multiple cases across several different controls, I have observed the objects with the same Width, Height, Font, and Font Size display different font sizes depending on where they are placed on my userform.
. . . .
Above is an example of this. The two textbox's are both 26H and 48W, with a Left of 90. Both have font Tahoma Regular size 18. The only difference between them is their Top property. And yet visually, the upper one has much wider text than the lower one. The picture on the right has added dots to prove this is not an optical illusion. The upper one can only fit one dot between the letter and the edge. The lower one can fit at least two dots between the letter and the edge.
Can anyone explain why this is happening? What is happening? Or how I could stop it from happening?
Why its happening?
A normal windows graphical application renders in 96dpi/ppi.
However, excel’s rendering system is in 72dpi/ppi,so, when you specify 26 as the height, excel will first convert 72 to 96 dpi.
26 x 96 / 72 = 34.6667
Which means your control height is 34.667 pixels.
This will create artefacts in the rendering of your control.
How can you stop it?
Make sure that the final position of your control and its height has a final pixel position in the form to be a whole number.
You can do this by multiplying by your screen dpi and divide by excel dpi(72)
In your case you can apply a height of 25.5 which will render it correctly.
I hope I solved your answer!!
As Krishna Soni says in this thread, you should use a height of 25.5 for all the reasons he present.
This is equivalent to using controls with a height that is a multiple of 3. Since the rounding of 25.5 is 30, we can take 3 as a multiple of the Top, Height, and Width properties and avoid the text resizing issues.
Seen on Weird change of font size when changing Top proprierty by 1
I'm using TCPDF::Polygon() to render coastline (land) coordinates from a text file on top of a blue TCPDF::Rect(). The text file contains coastlines for the entire world, however by specifying a center latitude and longitude in the map projection, together with some multiplication to get a 'zooming' effect, I manage to display the desired area within the A4 page.
Problem:
As you can see by the image the coastlines are drawn all the way to the edge of the document (and beyond). Although most of the coastline coordinates from the text file are 'outside' the document's visible area they are still taking up some hundred kilobytes in the output file.
Is there a nice way to 'crop' the coastline-polygon, so that the coastlines fit nicely inside the blue area and the excess vertecies are completely excluded from the document (not taking up file space)?
Solution:
The 'cropping' I was looking for is done using clipping, as suggested by #Rad Lexus:
// Start clipping
$pdf->StartTransform();
// Draw clipping rectangle
$pdf->Rect($DOC_MARG, $DOC_MARG, $MAP_W, $MAP_H, 'CNZ');
// -- Draw all polygons here (land areas) --
// Stop clipping
$pdf->StopTransform();
Source: https://stackoverflow.com/a/9400490/2667737
To save space in the output file I check every pixel in each polygon (land area) and render only the polygons that has one or more pixels within the bounds of the page - also suggested by #Rad. In the example view in my first post, the size was halved using this method.
Thanks for the help!
I don't think this is possible out of the box but wanted to make sure.
We'd like to do the following.
Take any image input and force the output width to be a fixed size. If the width is less than the output width, we'd like to center the image and add horizontal padding to the image but not add vertical padding.
For example
Original image is 700px x 400px
Final output size of 1000px width x 400px. This would include 150px padding left and 150px padding right (no top / bottom padding).
I know that we can upscale the image (scale=both) or set the canvas scale (but that adds top / bottom padding) or we could add padding to the image but none are really what we want.
Thanks for any help
Response to Nathanael
Your comments are exactly correct.
I expected http://z.zr.io/ri/red-leaf.jpg?width=1000&scale=canvas&bgcolor=gray to work exactly as it does
Yes, our problem is that the image heights are not known beforehand, but it's good to know that this works with a known height
I think it would be great if there was a command for scale=padwidth that would work with variable heights. Or a setting for padwidth=true and padheight=false that could be used in conjunction with scale=canvas.
So, let's say that you're given an 800x600px image, and you apply ?width=1000&scale=canvas. You were expecting that this would produce a 1000x600px image, but instead it produced a 1000x750px image, right?
http://z.zr.io/ri/red-leaf.jpg?width=1000&scale=canvas&bgcolor=gray
If you specify the height explicitly, the padding goes away - but you may not know the image height beforehand, correct?
http://z.zr.io/ri/red-leaf.jpg?width=1000&scale=canvas&bgcolor=gray&height=600
What would be the least surprising behavior - maintaining aspect ratio, or only adding the minimum padding required? How would you expect this to behave, or be exposed as a command?
Very simply I have a script that calls imagemagick on my photos.
The original image is 320 x 444, and I want to create a few scaled down versions but keeping the same aspect ratio
I call imagemagick using
convert oldfile.png -resize 290x newfile.png
I want to scale it to my set widths but the heights scale accordingly.
I do 80x, 160x and 290x in 3 separate commands.
The smallest 2 produce images with the same original aspect ratio, the 290x does not.
The size of the image it produces is 290 x 402
I have no idea why that one fails to keep the aspect ratio but the other 2 sizes maintaine it.
Any ideas?
I think that the problem in the third command is the requested size itself:
in the first command both dimensions are divided by 4: 320/4=80 and 444/4=111
in the second command both dimensions are divided by 2: 320/2=160 and 444/2=222
444 and 320 have only two common divisors: 2 and 4. You already used these divisors in your first two commands, so any other (width, height) couple will give you a slightly different aspect ratio: it is impossible to obtain the same exact aspect ratio fixing 290.
In fact while your original image has an aspect ratio of 1.3875, with a 290x403 image you would obtain an aspect ratio of 1,389655172 and with a 290x402 image you would get a 1,386206897 ratio: fixing 290 there is no other dimension's value that can give you the desired aspect ratio.
In general however Imagemagick always tries to preserve the aspect ratio of the image, as you can read in Imagemagick documentation:
The argument to the resize operator is the area into which the image
should be fitted. This area is not the final size of the image but the
maximum sizes for the image. that is because IM tries to preserve the
aspect ratio of the image more than the final (unless a '!' flag is
given), but at least one (if not both) of the final dimensions should
match the argument given image. So let me be clear... Resize will fit
the image into the requested size. It does NOT fill, the requested box
size.
For further reference see here
I want to get the PlotArea width and height in order to calculate the proportion.
I used ActiveChart.PlotArea.Width to get the width, and then tested the width using Photoshop.
I discovered that the width returned by ActiveChart.PlotArea.Width is wrong.
Image shows what I am talking about:
I have no Idea why...
Please help me to understand why it happens and how to fix it...
Thanks!
PlotArea.Width is returning the width in points not pixels.
http://msdn.microsoft.com/en-us/library/ff198324.aspx
Points are a unit of length. Pixels are variable on a number of factors like monitor, fonts, truefont settings, ect. Here is a SO post about converting pixels to points: Convert Pixels to Points