I am drawing text in a PDF page using iTextSharp, and I have two requirements:
1) the text needs to be searchable by Adobe Reader and such
2) I need character-level control over where the text is drawn.
I can draw the text word-by-word using PdfContentByte.ShowText(), but I don't have control over where each character is drawn.
I can draw the text character-by-character using PdfContentByte.ShowText() but then it isn't searchable.
I'm now trying to create a PdfTextArray, which would seem to satisfy both of my requirements, but I'm having trouble calculating the correct offsets.
So my first question is: do you agree that PdfTextArray is what I need to do, in order to satisfy both of my original requirements?
If so, I have the PdfTextArray working correctly (in that it's outputting text) but I can't figure out how to accurately calculate the positioning offset that needs to get put between each pair of characters (right now I'm just using the fixed value -200 just to prove that the function works).
I believe the positioning offset is the distance from the right edge of the previous character to the left edge of the new character, expressed in "thousandths of a unit of text space". That leaves me two problems:
1) How wide is the previous character (in points), as drawn in the specified font & height? (I know where its left edge is, since I drew it there)
2) How do I convert from points to "units of text space"?
I'm not doing any fancy scaling or rotating, so my transformation matrices should all be identity matrices, which should simplify the calculations ...
Thanks,
Chris
Related
Playing with Unicode to create symbols with the already large set of combiners and other modifiers allows to already go far.
Although, there are times where some arrows are only given in a single direction, or a diacritic is available only placed above, but not for example bellow on the left side.
So are they modifiers/combiners that allow to instruct such a composition?
For example, the combining rectangle allows to make something like a̻. At least on the current terminal, it's rendered with a rectangle on the above right position compared to the a glyph to which it's combined, having it's longest side oriented horizontally. Now, what if :
the goal is to place the rectangle at the top left, top middle, etc.?
the goal is to rotate the rectangle before it's combined with the main glyph?
the goal is to mirror the rectangle before it's combined with the main glyph?
Obviously the last point don't make much difference for a rectangle, but for asymmetric glyphs it would.
No, there is no such mechanism in Unicode. Different positional variants of the same diacritic are encoded as separate characters. For example, U+0307 COMBINING DOT ABOVE, U+0358 COMBINING DOT ABOVE RIGHT, and U+1DF8 COMBINING DOT ABOVE LEFT are all different codepoints. There is currently no way to represent, say, a generic combining dot below right in Unicode.
Similarly, arbitrary Unicode characters cannot be mirrored or rotated. Where such transformations make a meaningful distinction (for example the pair “E” and “Ǝ”), they have once again been encoded atomicly.
There are some very specific circumstances where such modifiers can be applied. In Sutton SignWriting, rotation is a productive feature. Rotating glyphs is necessary to display text correctly, so a number of rotation modifiers have been defined. For example, U+1D800 SIGNWRITING HAND-FIST INDEX points upwards in its base orientation (𝠀), but by appending U+1DAA1 SIGNWRITING ROTATION MODIFIER-2 you can make it point north-west instead (𝠀𝪡).
For emoji only, Unicode also specifies a mechanism for defining whether a given glyph is supposed to face left or right. For example, “🚗⬅️” would be an automobile going to the left and “🚗➡️” would be an automobile going to the right. No commercially available fonts presently support this mechanism, however.
I was visualizing my vorticity vector field and notice that I am not able to see the pattern without zooming in as there are too many glyphs and are too packed.
Currently, I am using a calculator to combine X,Y,Z vorticity field into a single vector field using the calculator. Take a slice of it and do a glyph filter visualizing all points on the plane.
I notice that one possible way is to visualize a curved glyphs and scale up a little bit to make it more noticeable, but not sure how to do that. Does anyone know whats the steps to do that? Or any other suggestions?
TIA
Have you tried reducing the Maximum Number of Sample Points property in the Properties Panel when the Glyph filter is selected in the Pipeline Browser? You may also want to change the Scale Factor property to change the length of the glyphs.
I would like to have a text box rescale with the level of magnification, such that one unit of text is always assigned one unit of horizontal axis-length. The text width should not change but rather the spacing between characters.
For instance, if the x-axis displayed [0:50], fifty characters should be displayed, one at each integer position. If the magnification was increased such that the display comprised only [0:10], only ten characters would be displayed, again placing one character at each integer position along the horizontal axis.
Finally, the text would ideally not display when the magnification level was below some threshold determined by the number of characters that can be legibly printed along a horizontal line spanning the extent of the axes.
I have tried using the text object, but it doesn't seem to have the relevant properties to allow such dynamic behavior. I have instead considered breaking the N-length string into N unit-length strings and placing each at a defined x-position, but I'm having trouble figuring out how to display only those relevant at the prevailing zoom level (there is some spill-over of characters beyond the bounds of the axis). In contrast, with this approach, all the characters appear as a jumble at zoom levels so low that the number of characters printed cannot be reasonably accommodated.
Thus, I inquire whether another solution besides printing a series of unit-length strings might be advised and, if not, how the twin problems of text spill-over and text overlap can be resolved at high and low zoom, respectively (the first might be done by somehow preventing printing of information outside the axes; the second seems to require some dynamic magnification-aware means of suppressing text output at or above a certain x-axis extent).
I am creating a Microsoft Word document using the OpenXml library. Most of what I need is already working correctly. However, I can't for the life of me find the following bit of information.
I'm displaying an image in an anchor, which causes text to wrap around the image. I used WrapSquare but this seems to affect the last line of the previous paragraph as shown in the image below. The image is anchored to the second paragraph but causes the last line of the first paragraph to also indent around the image.
Word Screenshot http://www.softcircuits.com/Client/Word.jpg
Experimenting within Word, I can make the text wrap how I want by changing the wrapping to WrapTight. However, this requires a WrapPolygon with several coordinates. And I can't find any way to determine the polygon coordinates so that they match the size of the image, which is in pixels.
The documentation doesn't even seem to indicate what units are used for these coordinates, let alone how to calculate them from pixels. I can only assume the calculation would involve a DPI value, but I have no idea how to determine what DPI will be used when the user eventually loads the document into Word.
I would also be satisfied if someone can explain why the issues described above is happening in the first place. I can shift the image down and the previous paragraph is no longer affected. But why is this necessary? (The Distance from text setting for both Left and Top is 0".)
The WrapPolygon element has two possible child elements of LineTo and StartPoint that each take a x and y coordinate. According to 2.1.1331 Part 1 Section 20.4.2.9, lineTo (Wrapping Polygon Line End Position) and 2.1.1334 Part 1 Section 20.4.2.14, start (Wrapping Polygon Start) found in the [MS-OI29500: Microsoft Office Implementation Information for ISO/IEC-29500 Standard Compliance]:
The standard states that the x and y attributes are represented in
EMUs. Office interprets the x and y attributes in a fixed coordinate
space of 21600x21600.
As far as converting pixels to EMUs (English Metric Units), take a look at this blog post for an example.
I finally resolved this. Despite what the standard says, the WrapPolygon coordinates are not EMUs (English Metric Units). The coordinates are relative to the fixed coordinate space (21600 x 21600, as mentioned in the quote provided by amurra).
More specifically, this means 0,0 is at the top, left corner of the image, and 21600,21600 is at the bottom, right corner of the image. This is the case no matter what the size of the image is. Coordinates greater than 21600 extend outside the image.
According to this article, "The 21600 value is a legacy artifact from the drawing layer of early versions of the Microsoft Office."
I'm using FreeType2 for font rendering, and I need to get a global bounding box for all fonts, so I can align them in a nice grid. I call FT_Set_Char_Size followed by extracting the global bounds using
int pixels_x = ::FT_MulFix((face->bbox.xMax - face->bbox.xMin), face->size->metrics.x_scale );
int pixels_y = ::FT_MulFix((face->bbox.yMax - face->bbOx.yMin), face->size->metrics.y_scale );
return Size (pixels_x / 64, pixels_y / 64);
which works, but it's quite a bit too large. I also tried to compute using doubles (as described in the FreeType2 tutorial), but the results are practically the same. Even using just face->bbox.xMax results in bounding boxes which are too wide. Am I doing the right thing, or is there simply some huge glyph in my font (Arial.ttf in this case?) Any way to check which glyph is supposedly that big?
Why not calculate the min/max from the characters that you are using in the string that you want to align? Just loop through the characters and store the maximum and minimum from the characters that you are using. You can store these values after you rendered them so you don't need to look it up every time you render the glyphs.
I have a similar problem using freetype to render a bunch of text elements that will appear in a grid. Not all of the text elements are the same size, and I need to prerender them before I know where they would be laid out. The different sizes were the biggest problem when the heights changed, such as for letters with descending portions (like "j" or "Q").
I ended up using the height that is on the face (kind of like you did with the bbox). But like you mentioned, that value was much to big. It's supposed to be the baseline to baseline distance, but it appeared to be about twice that distance. So, I took the easy way out and divided the reported height by 2 and used that as a general height value. Most likely, the height is too big because there are some characters in the font that go way high or way low.
I suppose a better way might be to loop through all the characters expected to be used, get their glyph metrics and store the largest height found. But that doesn't seem all that robust either.
Your code is right.
It's not too large.
Because there are so many special symbols that is vary large than ascii charater. . view special big symbol
it's easy to traverse all unicode charcode, to find those large symbol.
if you only need ascii, my hack method is
FT_MulFix(face_->units_per_EM, face_->size->metrics.x_scale ) >> 6
FT_MulFix(face_->units_per_EM, face_->size->metrics.y_scale ) >> 6