I'm a bit confused setting the character width and height fields of the character size object ( example from the as described in the FreeType tutorial)
error = FT_Set_Char_Size(
face, /* handle to face object */
0, /* char_width in 1/64th of points */
16*64, /* char_height in 1/64th of points */
300, /* horizontal device resolution */
300 ); /* vertical device resolution */
Why are char_width and char_height specified? Shouldn't that depend on the actual glyph? For example the characters "w" and "l" have different widths and height.
Also, as I am not rendering to screen (I plan to use the raster font data for some other esoteric purpose) is it sufficient to use FT_Set_Pixel_Sizes instead?
The functions FT_Set_Char_Size and FT_Set_Pixel_Sizes set the size, not of an individual character, but of the em square for the font, which is a notional square that may be as tall as the tallest character (e.g., a square bracket: '[') but may not in fact be the same height as any character; it simply defines a reference dimension. The main meaning of setting a size of 12pt is to create characters that usually fit on to baselines 12pt apart without clashing, and which harmonize with 12pt characters from other fonts. An 'em' is thus a typographic dimension representing the size of the font.
The height and width are separately settable so that you can create expanded (horizontally enlarged) or condensed (horizontally compressed) fonts by using a larger or smaller width than the height. Normally you leave the width at zero, meaning that the width of the em square is to be the same as the height, and the characters are to be created in their standard proportions and not stretched or shrunk.
There is no reason to use FT_Set_Char_Size rather than FT_Set_Pixel_Sizes other than the fact that FT_Set_Char_Size gives finer control; FT_Set_Pixel_Sizes does not allow fractional pixels, which are meaningful when creating anti-aliased glyphs. The end result is always calculated using both the em size and the display resolution.
In your case you might as well use FT_Set_Pixel_Sizes; but if you need a fractional pixel size, use FT_Set_Char_Sizes with height in 64ths of a pixel, width of zero, and zero for both horizontal and vertical device resolution; a resolution of 0 makes pixels the same size as points. So to get a pixel size of 11.5, you'd use
FT_Set_Char_Sizes(face,0,11 * 64 + 32,0,0);
Related
I have pictures in .dcm format.
I'm looking for the width and length of the pixel.
As far as I know that Dicominfo gives the information of the picture.
Do you know what parameters are used to obtain the width and length of the pixel in the Dicominfo?
I had an idea that I first need the FOVx "Field Of View" and then I can divide by the number of pixels. This is how I get the width and length of the pixel.
I am very grateful for every answer.
Not sure what you exactly mean by "length". Furthermore, geometrical information (pixel size in mm) may vary regarding the tag numbers, depending on the type of object. The attribute tags I am providing here should work for the majority of DICOM images that have geometrical information at all.
image size in pixels (x,y) -> Columns (0028,0011), Rows (0028,0010)
size of the pixels (y,x) -> Pixel Spacing (0028,0030)
Pixel Spacing is a multi-valued attribute from which you can obtain two values which are separated by a Backslash "\". Not sure how the API of DicomInfo allows access to multiple values in the same attribute.
Note the difference "(y,x)" in Pixel Spacing. This is very unintuitive, but it is like it is.
I am displaying bitmaps with the function SetDIBitsToDevice. This function knows about the total image size via a LPBITMAPINFO structure that has Width and Height fields. It also knows about the region of interest to be drawn via the arguments XDest, YDest, Width, Height. All these are specified in pixels.
So far so good when the image is stored as a canonical one, i.e. with a row pitch (number of bytes between a pixel and the one immediately below) that matches the image width in bytes, with padding (if necessary) to reach the next multiple of four bytes.
For technical reasons, I have images with a larger pitch (but still a multiple of four). For instance, width=1000 but pitch=1024. For a grayscale image (1 byte per pixel), I can trick the function by declaring a width of 1024 in LPBITMAPINFO and a width of 1000 when passed to SetDIBitsToDevice.
But for a 3 bytes per pixels image (RGB), I am stuck because 1024 bytes do not correspond to an integer number of pixels, and I see no way to specify that pitch.
Do you see a workaround or something I missed in the documentation ? (I don't think that the field SizeImage can be of any use.)
Maybe it's just my head spinning, but there seems to be no documentation on the units of measure for HPDF's HPDF_Font_TextWidth() function, nor can I figure it out.
The number I get for a particular text of 7 characters is around 3000. The rendered text seems to be around 80 pixels, which is also returned from HPDF_Page_TextWidth().
HPDF_Font_TextWidth() does not know the font size so it must use some other unit. What is it?
And is that the same unit that HPDF_Font_GetBBox() returns?
I'm actually trying to put text in the center of a rectangle, and need the width and height of the text in the units of the rectangle.
This is an old post but I just stumbled upon it because I had the same issue. As far as I know, looking into the source of HPDF_Font_GetUnicodeWidth(), the units that it returns needs to be multiplied by the font size, then divided by 1000 to get the width in points, which is what the rest of the PDF coordinate system uses.
width = (HPDF_Font_TextWidth() * font_size) / 1000.0;
All the following return EM units, which must be divided by 1000 and multiplied by the point size to get points, as stated above:
The units are relative to the baseline. Descender, BBox left & bottom are negative. The zone between caps Height and ascender is for diacritics.
To calculate the height of a slug of text, compute caps height less descender, or ascender less descender if your text has upper-case diacritics.
Keyword: Haru PDF
My math must be very rusty. I have to come up with an algorithm that will take a known:
x
y
width
height
of elements in a document and translate them to the same area on a different hardware device. For example, The document is being created for print (let's assume 8.5"x11" letter size) and elements inside of this document will then be transferred to a proprietary e-reader.
Also, the known facts about the e-reader, the screen is 825x1200 pixels portrait. There are 150 pixels per inch.
I am given the source elements from the printed document in points (72 Postscript points per inch).
So far I have an algorithm that get's close, but it needs to be exact, and I have a feeling I need to incorporate aspect ratio into the picture. What I am doing now is:
x (in pixels) = ( x(in points)/width(of document in points) ) * width(of ereader in pixels)
etc.
Any clues?
Thanks!
You may want to revert the order of your operations to reduce the effect of integer truncation, as follows:
x (in pixels) = x(in points) * width(of ereader in pixels) / width(of document in points)
I don't think you have an aspect ratio problem, unless you forgot to mention that your e-reader device has non-square pixels. In that case you will have a different amount of pixels per inch horizontally and vertically on the device's screen, so you will use the horizontal ppi for x and the vertical ppi for y.
assuming your coordinates are integer numbers, the formula x/width is truncating (integer division). What you need is to perform the division/multiplication in floating point numbers, then truncate. Something like
(int)(((double)x)/width1*width2)
should do the trick (using C-like conversion to double and int)
May I know what are the ways to calculate the length of 1 pixel in centimeters? The images that I have are 640x480. I would like to compare 2 pixels at different places on the image and find the difference in distance. Thus I would need to find out what's the length of the pixel in centimeters.
Thank you.
A pixel is a relative unit of measure, it does not have an absolute size.
Edit. With regard to your edit: again, you can only calculate the distance between two pixels in an image in pixels, not in centimeters. As a simple example, think video projectors: if you project, say, a 3×3px image onto a wall, the distance between the leftmost and the rightmost pixels could be anything from a few millimeters to several meters. If you moved the projector closer to the wall or farther away from it, the pixel size would change, and whatever distance you had calculated earlier would become wrong.
Same goes for computer monitors and other devices (as Johannes Rössel has explained in his answer). There, the pixel size in centimeters depends on factors such as the physical resolution of the screen, the resolution of the graphical interface, and the zooming factor at which the image is displayed.
A pixel does not have a fixed physical size, by definition. It is simply the smallest addressable unit of picture, however large or small.
This is fully dependent on the screen resolution and screen size:
pixel width = width of monitor viewable area / number of horizontal pixels
pixel height = height of monitor viewable area / number of vertical pixels
Actually, the answer depends on where exactly your real-world units are.
It comes down to dpi (dots per inch) which is the number of image pixels along a length of 2.54 cm. That's the resolution of an image or a target device (printer, screen, &c.).
Image files usually have a resolution embedded within them which specifies their real-world size. It doesn't alter their pixel dimensions, it just says how large they are if printed or how large a “100 %” view on a display would be.
Then there is the resolution of your screen, as others have mentioned, as well as the specified resolution your graphical interface uses (usually 96 dpi, sometimes 120)—and then it's all a matter of whether programs actually honor that setting ...
The OS will assume some dpi (usually 96 dpi on windows) however the screens real dpi will depend on the physical size of the display and the resolution
e.g a 15" monitor should have a 12" width so depending on the horizontal resolution you will get a different horizontal dpi, assuming a 1152 pixel screen width you will genuinely get 96 dpi