I'm trying to change the letter spacing in a NSFont (such as Gill Sans). Is this possible or will I need to load my own custom font?
Though I suppose fonts might specify some kerning hints, kerning is really an attribute of rendered text. So the answer to your question depends on how you're going to render your text to the screen.
If you're using NSAttributedString, you can look at the NSKernAttributeName attribute (see the Constants section in the documentation. If you're using CoreText and CFAttributedString, you can look at the kCTKernAttributeName attribute (see the Constants section in the documentation.
If you're using something else to render text, then the answer (if there is one; not all text rendering methods support advanced customization) will be dependent on that something else.
Related
With Markdown, I can simply:
[`a link with monospace font`](https://www.example.com)
a link with monospace font
Note how the above line is properly rendered by SO's MD renderer: the link text is in code (monospace) syntax.
I'm trying to achieve the same with reST:
I've tried to do this in reST with
```a link with monospace font`` <https://www.example.com>`_
But that breaks the linking, I get a monospaced text with a link with monospace font and then a link with https://www.example.com as the link text.
The problem seems to be Docutil's lack of support for nested inline markup. Frankly, I don't understand how's that possible. Docutils ToDo lists a discussion from 2001! We're in 2022! Not only this really basic feature is missing, but my impression is also that there's no real interest in ever implementing it.
I don't think the different workarounds are reasonable for such a simple feature.
Pandoc has an open bug for the exact same problem/
How can I get an HTML link test rendered as a literal without any workaround when using reStructuredText?
I've been searching through a large number of CKEditor posts and have yet to find a targeted answer to this question. I know CKEditor is very configurable (which I haven't leveraged yet.)
For every formatting action performed, CKEditor wraps it in a separate span tag. So if I 1) change the font to Arial 2) change the size to 36px 3) change the color, I end up with this HTML which seems unnecessarily verbose.
<p><span style="color:#DAA520"><span style="font-size:36px"><span style="font-family:arial,helvetica,sans-serif">Hi</span></span></span></p>
I would rather it just did something like <p style="..styles list">Hi</p>
My question: Is this configurable (and how), and/or is there a rationale for them doing it this way where I should just accept the behavior?
It certainly seems like a relatively clean means of implementation on CK Editor's part, and would help it avoid conflicting logic for different styles applied to dissimilar spans.
If you as the user want consistent differences with multiple variables like size, color, or font, you should really be using classes, I would think. A WYSIWYG editor like CK is designed to implement HTML code that is readable, not pretty. If you want more elegant code, you probably need to write it yourself.
Since other adaptations from WYSIWYG editors/ word processors generate obscene looking code, e.g. Microsoft Word/ Outlook, or Adobe's new CSS from layout feature, this span output isn't actually too bad.
I'm doing color transformations on glyphs rendered with CTFontDrawGlyphs, but I do not want to do those transformations to the emoji glyphs, since they have already a meaningful color information.
So, when I have a CTRun of glyphs, can I detect if it is actually emoji/color font?
I can do a string compare to the postscript name with "AppleColorEmoji", but seems awfully wasteful to do all the time, and somewhat hacky if there ever happens to be another font with the same features.
Ah, I can get the symbolic traits with CTFontGetSymbolicTraits, and check for kCTFontTraitColorGlyphs (or kCTFontColorGlyphsTrait), which, while undocumented, is available in the public headers.
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.
I'm doing some text rendering in Cocoa using NSAttributedString, and setting the font and underline properties, etc. However, I can't figure out how I can change the text's tracking. Any suggestions?
I don't think font tracking is an exposed property for text layout with attributed strings.
You could perhaps use the available expansion attribute on whitespace, and manually insert whitespace characters with scaling factors to influence their width, but I expect that would be a fiddly hack for anything other than trivial cases.
The only other route I can think of is to use your own custom attributes along with an NSLayoutManager subclass. The cocoa text system is extremely flexible, but with that flexibility comes a greater degree of complexity.
My solution so far has simply been to use the kerning attribute, as tracking and kerning are similar. Is there any better solution?