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).
Related
I would like to add vertical blank space between two lines in a Modelica component GUI. I have (in this case), six similar looking parameters/comments within a group on a tab that I would like to visually break into two plus four by using a little space after the second one (essentially a blank line, but ideally I would have some control over the gap space).
I can put the last four in a separate group with no name, which gives a line in between the two/four. This is better than nothing, but not really what I want. I tried using groupImage, but it locates the image relative to whole group, so if it's smaller than the six entries, it doesn't affect them at all; and if it's larger, it introduces uniform spacing between all the entries, rather than just between 2/3.
The way I understand how emacs displays stuff is that essentially everything is text. If you have something in the fringe or linum mode active, essentially your document is pushed a little inwards and something is written in the first few columns.
I'm writing a function for putting some stuff into the head-line and this works nicely, however, I would like the start of the text to be aligned with the start of the document.
Thus I am looking for a way to get the number of columns that sit between the frame border and the start of the actual document.
Let me illustrate using a poorly produced graphic:
I want to get the number of columns (or the number of pixels) that make up the distance marker by the ruler just below the line number 10000.
The function which returns this value shall be executed in the functions which create the head-line.
There is a function called window-inside-edges that you can use to determine the offset of the text area ("window body") from the total width and height of the window in columns and lines, respectively.
It returns a list four values; the order is left - top - right - bottom, so to get the value you are interested in for the current window, just do
(car (window-inside-edges))
More information on window coordinates can be found here; this page has information about window sizes, including a nice ASCII representation of window elements.
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
Certain emacs function splits the current frame, for example magit-status or compile (probably there are dozens). How emacs decides whether to do a vertical split or a horizontal one?
My experiments suggests that if the frame's width is larger then 162 chars then it dose a vertical split, and otherwise a horizontal one. Is it the right value? More important, where is this value stored, how can I change this threshold?
split-width-threshold:
Minimum width for splitting windows sensibly. Hide If this is an
integer, split-window-sensibly may split a window horizontally only
if it has at least this many columns. If this is nil,
split-window-sensibly is not allowed to split a window horizontally.
Standard value is 160 here, looks pretty close to what you've found.
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