I have the following problem with Tikz/Latex:
I have some nodes that contain text. Most text doesn't have letters that reach below the baseline. But for those nodes where it happens, the ratio and placement of node height and text/baseline is off. Have a look at the example image.
Solutions I know of:
make the nodes' minimum height bigger. This results in the nodes being sized the same, but the baseline is still at different heights
use struts. This results in all nodes being laid out like the ones containing the offending text. This results in too much space between the baseline of the text and the surrounding box for most nodes
There's a property for nodes: text depth
One can simply set it to 0pt for the offending (or all) nodes.
Note
Of course this is well documented in the pgfmanual.
This is more of a pointer (can't get TikZ at the moment), but since you are not getting anything else, there are two things to try:
1) There is the $\smash[b]{\text{my text y}}$ (you need amsmath for this).
2) Maybe \raisebox{0pt}[0pt]{my text y} is what you want.
Related
please see the image below for two examples of what is to be achived
the alignment should be on the Center Y of the first lines of each UILabels and should work regardless of font size or font. currently we have implemented this with different constraints to the top of the super view for different font and font size combinations.
the constraint to align the center of the two UILabels does not work since the text of the second UILabel is not fixed and can have several lines.
also the text is dynamic, so it is not known where the text will wrap to create the first line, thus it cannot be shown in an one line UILabel with the rest of the text in another one below.
currently this is implemented using UIKit, but if there is an easy solution in SwiftUI we can put these two labels in a SwiftUI component. so a SwiftUI solution would also be welcomed.
Your comments said "it should be on the glyphs" ... but, without additional information, my guess is that "real world" usage would not really need that level of precision.
For example:
While the glyphs are not perfectly center-Y aligned, it seems unlikely you'd run into a case where the first line of the "rightLabel" is " ' " ' " or . , . , ..
This layout can be easily done with only a few constraints - no need to do any calculations:
The "Positioning" label would, of course, be set .hidden = true so it would never be seen.
If you really, really want glyph-precision, you'll need to calculate
the Glyph bounding box for the left-label
the Glyph bounding box for first line of the right-label
calculate the "character box" offsets to align the Glyph Y-centers
and then position the two labels accordingly, or use Core Text to draw the text (instead of using UILabel).
Probably more work than necessary -- unless your actual use-case demands it.
That's an interesting problem! You can try using the centerYAnchor for the label on the left, and the firstBaselineAnchor for the label on the right... that will align the center Y with the text baseline, which isn't quite what you want.
To find the correct offset to apply, you can use the information from UIFont about the size of the characters. I'd probably start with capHeight * 0.5 and see if that looks or feels right. Something like:
leftLabel.centerYAnchor.constraint(equalTo: rightLabel.firstBaseLineAnchor, constant: rightFont.capHeight * 0.5)
This is a more difficult problem in SwiftUI, I think, because resolved font metrics aren't directly available to you.
For the context, I'm working with Capella, an Eclipse RCP application based on Sirius (hence, EMF, GMF and draw2d). This application is used for MBSE, that basically means diagram representations for industrial systems.
I'm developping an add-on (viewpoint) to display custom labels next to diagram elements. These diagram elements are, to put it simply, boxes inside boxes. My problem is that usually the label text is larger than the space between a box and its container, so the label gets hidden. What I need is these labels to always be in foreground. As I'm more used to web development, what I'm looking for would be the equivalent of the z-index CSS property.
Currently I have no idea of how to achieve this, I'm using a custom .odesign that allows me to control some rendering options, like labels text, the color of some elements or to add decoration, but I dont think its the way to go for my problem. Maybe I should use a custom EditPart or a custom StyleConfiguration (I already used these components for other projects) but I have no clue where to start for this issue.
Any leads will be greatly appreciated.
We recently did this kind of changes to keep some labels in Sirius Sequence diagrams always on top: the combined fragments are placed behind the lifelines (z order) but we wanted to keep the labels of the CombinedFragments visible event their bounds intersects Lifelines, Executions or States).
This has been handled in Bug 564239 for Sirius 6.3.2 (used in Capella 1.4.1).
You could find some hints the bugzilla (Gerrits and commits can be retrieved from the See also section).
In Sirius Sequence diagram , we use org.eclipse.sirius.diagram.sequence.ui.tool.internal.layout.SequenceZOrderingRefresher to control the z-order of CombinedFragments : all the figures that composes them comes from some expressions in the odesign, and synchronization with the Capella model for exemple.
But in your case you want to control only the label, so it must not be dealt on the edit par level, but on the figure one. The "overlay" layer and figure lead might be a good one.
Do not forget another thing: in GMF/GEF, the labels of an element is displayed/shown/rendered/visible if it fits to the visible area of the parent container: in the case of a node in a container with scrollbar, the visible are will impact the visibility of the sub nodes (extended to their border nodes, edges, labels, ...)
Regards
Maxime
A multiline auto typing text box class (which uses an SKNode as the parent) is created using basically 2 elements:
an SKSpriteNode that acts as text box frame & background image/texture holder.
an NSMutableArray containing a set limited amount (rows) of NSStrings that each have a set character length.
After modifying this text box class so that it can be initialized with any frame width & height, I realized I didn't program the NSMutableArray to automatically change its content in a such way that it nicely fits within the background node (with a bit of padding involved as well). So here I am wondering how to do that since NSString's can only return the character count and not the width & height of each string in points (points could have maybe helped me create character constraints in some way).
Right now, the NSMutableArray uses a hardcoded maximum character count per NSString & a maximum row count for the entire array (it's 5 rows right now and when that limit is reached, a new "page"/array is created). This forces me to manually re-adjust these parameters every time I change the background node frame size which defeats the purpose of the class allowing the background frame to change.
Thing is, I'm trying to solve this in such a way that when I post this class on github, I want the solution to take into consideration any fontName & fontSize.
What are my options for solving this problem?
I've done something similar to this. It doesn't work 100% as to what you want, but should be similar enough. It uses a root node and from there, it will build multi-line text using an array of NSString which will in turn be used to build the SKLabelNode.
I'll outline what I did. I should also say I only run this when new text is set. In other words, I do not incur the penalty of deriving the information every frame. Only once.
The generalized steps are:
You will iterate over each character in the text string. Note I do this because my code supports word wrapping as well as other alignment capabilities. So for me, I want that level of control. As this is being done only upon creation, I'm fine with the overhead. If you don't want to word wrap you could always just create an array of words and work from there.
As you iterate over each character, you'll be generating an array of lines. Where each line in the array is a line that will fit in your frame. For now let's not worry about vertical constraints. So here we are primarily worried about width. For the current line, each character you are iterating over will get added to the current line. For this potential line string, you will use NSString's sizeWithAttributes, which is configured for your font. For example in my code it is an NSDictionary which contains: NSFontAttributeName : [UIFont fontWithName:self.fontName size:self.size]. This will be used to check the width, if that width exceeds the frame width, you are overrunning the line.
So the code may look something like:
size = [line sizeWithAttributes:attributes];
if (size.width > maxTextWidth) {
needNewline = YES;
}
If you have overrun a line, you need to determine if you are word wrapping. If you are, you can just add the current line (minus one character) to the lines array. If not you have prune off the last word in the current line and then add that to the array of lines.
The tricky parts are dealing with whitespace and handling non-word wrapped overflow. I have not addressed whitespace but you need to consider this very much in your code. Additionally, you also do want to factor in leading pixels, etc.
Once you have your array of lines, you can then create your children SKLabelNodes. I add them to the root, which allows me to move the group anywhere it needs to be.
The real key here is the lines array generation.
I am writing a vba macro that checks that word documents are formatted correctly to meet certain specifications. One of the things I have to check for are the left margins of each line - different paragraphs are supposed to have different first indents and hanging indents depending on the context. This should be as simple as checking the style, but unfortunately it is not - some of the documents use styles to change the indents, but others use manual spaces and tabs to position the text correctly. So I need some way to check the actual physical position of the first physical character in each Document.Paragraphs. I have no problem getting a range with the first visible character in the paragraph, but I'm not sure about getting the distance from the margin (or from the left side of the page - doesn't make a difference because the margins are consistent).
I found the Window.GetPoint method, but I'm nervous to use it, because that is based on the actual physical location on the screen. This macro is going to be used on different computers, with different versions of word, and I'm not sure about how it is affected by other view settings (like print layout, zoom, etc.) Is there a consistent way to use this method to determine the distance from the margin?
The other method would be (because all of the documents are in Courier New 12) to look at the firstindent property of the style, and the count manually all of the spaces and tabs (but that would need to take into account tabstops). This I'm also not sure how to do.
I would think that there should be a much simpler way of doing this, but I can't find it, so if anyone has any suggestions I would really appreciate any help.
It was there after all! Range.Information(wdHorizontalPositionRelativeToPage)
I have a two-column paper where space restrictions are very tight.
I just looked at my last version of the manuscript and saw that the upper half contains a figure (as expected), but in the lower half there is a lot of vertical space between paragraphs (enough to squeeze 10 more lines), and that LaTeX probably added it so that in the beginning of the next page a new numbered section will begin at the top of the page.
I know there's a way to adjust this so LaTeX doesn't try so hard, but I'm not sure how. any help? Thanks!
The parameter that controls inter-paragraph spacing is called \parskip(See Paragraph Spacing ). You set it (with "rubber" values) using something like:
\setlength{\parskip}{1cm plus4mm minus3mm}
The defualt value of \parskip is class dependent. The "plus" and "minus" parts tell TeX how much it can adjust the value to improve the layout (that is they make the spacing elastic, thus the "rubber" designation). Reducing (or eliminating) the "plus" part of the rubber might help.
Watch out though, you can cause other layout artifacts if you constrain TeX too much.
Other things to think about:
The widow and club penalties probably apply section headings, and may be affecting TeX's layout choices (see https://stackoverflow.com/questions/512967/how-can-one-keep-a-section-from-being-at-the-end-of-a-page-in-latex for a discussion).
You may also want to consider messing with \baselineskip which controls the allowed spacing between lines of text and can also have rubber values.
This is a common problem, and there are probably some fairly sophisticated treatments already prepared on CTAN.
\vfill before the new section worked perfectly for me.