Having struggles trying to get the following view to work across devices, this is just one of many of my auto-layout issues. I have some text next to a UISwitch, on devices that are large enough I am happy for the text to be on a single line but on smaller devices the text can be split across multiple lines, I just can't get it to work correctly, it either appears like the screenshot or somewhere else messed up no matter what constraints I try to apply.
The middle image is iPhone 7.
I know this question is old, but it is something I encountered myself recently.
In the storyboard, you should set the label's horizontal Content Compression Resistance Priority to 749.
Looks like the trailing side of the switch is not constrained to align with the trailing side of the text field and other UI elements. Also make sure there is no constraint for the width of the text, as this is what will stretch.
Related
I have started to use tmux and noticed that the lines that seperate the different panes are not entirely straight, instead there are small bumps. I think it might have something to do with the font, my thought is that characters from one "character-field" are overlapping into the next, which creates the little bumps. Does anyone know how I can fix this and get a straight line without bumps?
The font I use: Menlo
example of the bumpy lines
The problem was actually the terminal emulator I used, Alacritty, which lets some characters reach outside of their cell. To solve this issue, I switched to Kitty, which has better support for preventing characters from overflowing into other cells.
It seems not possible to view the exact margin between font-elements in XD (dev-view). Below you'll find a screenshot of a situation where we need to measure the exact distance between two Font-elements (XD developer-view).
It needs to bypass the line-height, but it doesn't. To be able to do this, we need the line-height to be zero. But when we edit the line-height in XD for a word or sentence on a single row, XD does not change that line-height.
Anybody encountered the same situation?
In this example the line-height is 32. We go to XD. Change it to zero, save it and SHARE FOR DEVELOPMENT. But the line-height remains 32. Also changing it to 1 instead of zero won't make any difference.
To fix this issue, you have to select the Text within Adobe XD. Right Click and select Path > Convert to Path. The margins around the Text will disappear and when in DEVELOPMENT view it becomes possible to see the right margin. A small problem remains. When you want to edit the text when it's a shape, you have to delete it and place a new text and turn it into a shape again. the text when converted to a shape
The default selector in Adobe XD will not give you the exact margin between two text. You have to convert the text layer into paths (Convert to Outlines) to get the exact margin.
But remember after converting text layer into path the text cannot be edited because now the letter are separate vector shapes.
To convert text layer into Path, select the layer and goto Object>Path>Click Convert to Path
You can use the Guides to drag one below your text and another one on top of the second text, and then you can see the distance between the 2 guides.
Check this youtube video for a quick tutorial on it. This is going to be a manual action. I don't think there's a key to press to check the distance automatically.
Im not sure how to express it so I posted a picture in link below.
It should look like this
Just enter the text on 3 lines like so:
MORE
AT
THE HALL
Then adjust the point sizes, leading, kearning, etc. to create the aesthetic you want.
In this case line 1 and 3 could have full justification.
You can use scaling of the text(as shown in the character panel in attached snapshot) because changing font size also moves the baseline and causes the text to shift downward.
These attributes are also exposed via scripting.
Note: I looked at the other questions similar to this one, and they were either outdated or not useful.
Unfortunately there are so many different screen sizes and that makes auto layout really confusing for me. I want to have a simple UIImageView to cover the entire screen no matter what screen size it is. So the dimensions of the UIImageView should change accordingly.
I tried adding constraints to squish the image and it worked fine. But an error in the debugger said that there was an error: UIViewAlertForUnsatisfiableConstraints
Is this a big deal? And if it is, how do I get the Image to fill the entire screen?
Edit: The game will have squares going down the screen, which the user must tap
It might be, or it might not be a big deal, depending on what you're doing and if you know what you're trying to accomplish. In my experience, this is usually an issue if you're trying to programmatically alter the frame of a view which already has set constraints (you shouldn't alter the frame by hand unless you really need it).
Without more detail, it's hard to say what the exact issue is.
This picture illustrates my predicament:
All of the characters appear to be the same size, but the space between them is different when presented in a RichEdit control compared with when I use ExtTextOut.
I would like to present the characters the same as in the RichEdit control (ideally), in order to preserve wrap positions.
Can anyone tell me:
a) Which is the more correct representation?
b) Why the RichEdit control displays the text with no gaps between the Asian Characters?
c) Is there any way to make ExtTextOut reproduce the behaviour of the RichEdit control when drawing these characters?
d) Would this be any different if I was working on an Asian version of Windows?
Perhaps I'm being optimistic, but if anyone has any hints to offer, I'd be very interested to hear.
In case it helps:
Here's my text:
快的棕色狐狸跳在懶惰狗1 2 3 4 5 6 7 8 9 0
apologies to Asian readers, this is merely for testing our Unicode implemetation and I don't even know what language the characters are taken from, let alone whether they mean anything
In order to view the effect by pasting these characters into a RichEdit control (eg. Wordpad), you may find you have to swipe them and set the font to 'Arial'.
The rich text that I obtain is:
{\rtf1\ansi\ansicpg1252\deff0\deflang2057{\fonttbl{\f0\fnil\fcharset0 Arial;}}{\colortbl ;\red0\green0\blue0;}\viewkind4\uc1\pard\sa200\sl276\slmult1\lang9\fs22\u24555?\u30340?\u26837?\u33394?\u29392?\u29432?\u36339?\u22312?\u25078?\u24816?\u29399?1 2 3 4 5 6 7 8 9 0\par\pard\'a3 $$ \'80\'80\cf1\lang2057\fs16\par}
It doesn't appear to contain a value for character 'pitch' which was my first thought.
I don't know the answer, but there are several things to suspect:
There are several versions of the rich edit control. Perhaps you're using an older one that doesn't have all the latest typographic improvements.
There are many styles and flags that affect the behavior of a rich editcontrol, so you might want to explore which ones are set and what they do. For example, look at EM_GETEDITSTYLE.
Many Asian fonts come in two versions on Windows. One is optimized for horizontal layout, and the other for vertical layout. That latter usually has the same name, but has # prepended to it. Perhaps you are using the wrong one in the rich edit control.
UPDATE: By messing around with Wordpad, I was able to reproduce the problem with the crowded text in the rich edit control.
Open a new document in Wordpad on Windows 7. Note that the selected font is Calibri.
Paste the sample text into the document.
Text appears correct, but Wordpad changed the font to SimSun.
Select the text and change the font back to Calibri or Arial.
The text will now be overcrowded, very similar to your example. Thus it appears the fundamental problem is with font linking and fallback. ExtTextOut is probably selecting an appropriate font for the script automatically. Your challenge is to figure out how to identify the right font for the script and set that font in the rich edit control.
This will only help with part of your problem, but there is a way to draw text to a DC that will look exactly the same as it does with RichEdit: what's called the windowless RichEdit control. It not exactly easy to use: I wrote a CodeProject article on it a few years back. I used this to solve the problem of a scrollable display of blocks of text, each one of which can be edited by clicking on it: the normal drawing is done with the windowless RichEdit, and the editing by showing a "real" RichEdit control on the top of it.
That would at least get you the text looking the same in both cases, though unfortunately both cases would show too little character spacing.
One further thought: if you could rely on Microsoft Office being installed, you could also try later versions of RichEdit that come with office. There's more about these on Murray Sargent's blog, as well as some interesting articles on font binding that might also help.
ExtTextOut allows you to specify the logical spacing between records. It has the parameter lpDx which is a const pointer to an array of values that indicate the distance between origins of adjacent character cells. The Microsoft API documentation notes that if you don't set it, then it sets it's own default spacing. I would have to say that's why ExtTextOut is working fine.
In particular, when you construct a EMR_EXTTEXTOUTW record in EMF, it populates an EMR_TEXT structure with this DX array - which looking at one of your comments, allowed the RichEdit to insert the EMF with the information contained in the record, whereby if you didn't set a font binding then the RTF record does some matching to work out what font to use.
In terms of the RichEdit control, the following article might be useful:
Use Font Binding in a Rich Edit Control
After character sets are assigned, Rich Edit scans the text around the
insertion point forward and backward to find the nearest fonts that
have been used for the character sets. If no font is found for a
character set, Rich Edit uses the font chosen by the client for that
character set. If the client hasn't specified a font for the character
set, Rich Edit uses the default font for that character set. If the
client wants some other font, the client can always change it, but
this approach will work most of the time. The current default font
choices are based on the following table. Note that the default fonts
are set per-process, and there are separate lists for UI usage and for
non-UI usage.
If you haven't set the characterset, then it further explains that it falls back to ANSI_CHARSET. However, it's most definitely a lot more complicated than that, as that blog article by Murray Sargent (a programmer at Microsoft) shows.