Custom monospaced font for code blocks?

[kc1]

Thanks for the info.

Being able to change the font would be a mix of visual preference and a need to use less-frequently-used Unicode characters that often don’t display correctly in standard fonts due to either not being included in the font or not being implemented correctly. I’m a linguist working with minority languages. Using a monospace font some times helps with distinguishing things from the main text (non-monospace) and ensuring examples, etc. line up correctly.

It would be fine with me if it were just in a stylesheet. I just saw the setting for the main font and thought that would be a natural place to put it. But either way would work.

Is it currently possible to set/edit a stylesheet that affects display/editing? I tried searching the documentation but didn’t come up with anything.

Thanks again!

[kc1]

Here’s an example where monospaced font in Bike doesn’t work correctly:

The text in both fonts is the same. In this case, I’m using stacked diacritics, and as you can see they don’t display correctly in the font, at least in Bike. Which font is being used? I could try and see if it displays correctly in other apps with that font too.

Incidentally, I had to paste the examples into Bike, as described in my other post: Crash when typing decomposed Unicode characters/diacritics

[jessegrosjean]

@kc1

Which font is being used? I could try and see if it displays correctly in other apps with that font too.

Bike is using the system defined monospace font. On my macOS Ventura computer that is resolving to a font named: .AppleSystemUIFontMonospaced-Regular

[kc1]

@jessegrosjean

.AppleSystemUIFontMonospaced

I can’t find that specific font on my system, but it looks like maybe an Apple default? I’m not sure. Using different Apple system fonts, I get similar poor results in other apps (either the diacritics are like the screenshot above or they overlap each other instead of being stacked).

What does it look like if you copy and paste à̃hmà̃ ɡū̃mā̃ mù̃hmù̃ʔ into a code block in Bike?

Thanks again!

[jessegrosjean]

This is what I see after “Reset Typography” in Bike Settings on macOS 13.0.1 (22A400):

What version of macOS are you using?

[kc1]

I’m on the same version of macOS.

I reset the typography too and did some more testing. It looks like copy and pasting from different apps adds another twist. The following is the same text pasted from/through various apps into Bike:

The top line in each section are copied pasted from one app directly into Bike, while the second line is pasted from the first app, then to a second app, and then into Bike. The text was originally typed using decomposed characters.

It looks like this has to with how each app is handling Unicode normalization.

Apparently copy and pasting from the first app results in a precomposed à, etc. followed by the combining tilde. Copying through the other app results in each vowel with a combining grave accent and a combining tilde. The font correctly handles the second line (base character with two combining marks), but not the combination of a precomposed character with a combining mark.

So this is indirectly a font issue. But depends on how each app handles Unicode normalization.

Some other fonts might handle either normalization the same way, while others don’t know what to do.

Incidentally, what Unicode normalization method, if any, does Bike use?

Thanks again!

[jessegrosjean]

@kc1

The following is the same text pasted from/through various apps…

Which apps? I’m trying TextEdit and Pages, but so far am not seeing the problem

@kc1

Incidentally, what Unicode normalization method, if any, does Bike use?

None at the moment, at least none in Bike’s core code. Bike imports data using different methods (ie rich text, plain text, html, etc) so it may be that the parses/decoders uses by the individual import methods perform some normalization, I’m not sure.

[kc1]

@jessegrosjean

Which apps? I’m trying TextEdit and Pages, but so far am not seeing the problem

I did some more experimenting with different apps, and based on the results, I’m not sure whether the keyboard outputs precomposed or decomposed characters . Here are some results:

Typing in that app and then copying and pasting to Bike results in the Type items, while copying from Safari, pasting to apps, then copying again and pasting to Bike results in the Copied and Pasted from Safari items.

Typing in Pages, Drafts, and CotEditor looks fine in those apps, but pasting the typed items from those apps to Bike only displays correctly from Pages.

Typing in TextEdit looks bad in TextEdit as well as in Bike.

Safari, Pages, Drafts, and CotEditor all display correctly in those apps when typing in those apps.

So now I’m not really sure.

@jessegrosjean

None at the moment, at least none in Bike’s core code. Bike imports data using different methods (ie rich text, plain text, html, etc) so it may be that the parses/decoders uses by the individual import methods perform some normalization, I’m not sure.

That makes sense.

[kc1]

I don’t know how to resolve the Unicode issues, or if Bike should.

But I did discovered that changing fonts in other apps does help to resolve some of the display issues. Which brings back the original intent of this thread about fonts. You said:

@jessegrosjean

I think maybe it would be better handled with stylesheet.

Is it currently possible to change styles when editing in Bike using a stylesheet? Or is that something you are thinking of for the future?

Thanks again!

[jessegrosjean]

@kc1

Is it currently possible to change styles when editing in Bike using a stylesheet? Or is that something you are thinking of for the future?

No, just a future possibility. Generally instead of adding tons of visual preferences to Bike’s settings I would rather put them in stylesheet… but that’s still future work.

Thanks for all those test cases, I’ll, see if I can figure out what’s going on and if Bike can fix on its end.

[kc1]

Thanks! I think the stylesheet option would be more than adequate.

[jessegrosjean]

I will eventually, but I think it’s no longer needed for the original goal right? Bike’s existing monospace font can draw unicode accents/etc correctly, at least some of the time. That makes me thing that changing font won’t fix problems if they appear.

About those problems… I’m trying to recreate some of your test cases, but am having a hard time. For example I would like to reproduce but for CotEditor > Typed.

I have IPA Unicode Keyboard installed, and I’m able to type stacked accents with it, but when I type those in CotEditor then copy and paste into Bike the results I see are always good, not broken apart.

On issue may be that I’m not typing exactly what you typed. Does the bug require that you type that entire line? Or is it possible to reproduce the bug with a shorter bit of text? Could you tell me the minimal exact key sequence to key into CotEditor to recreate the problem?

Thanks!

[kc1]

Hi again. Thanks for trying to recreate the bug. I’ve done some more investigation and have a few more things to report.

I’m running my tests now just with one letter and two diacritics: à̃, which on the IPA keyboard is
the following keystrokes: a @ 1 @ ~.

I’ve discovered that CotEditor has a helpful tool that lets you inspect what Unicode code points a selected character has. You can find it by selecting a letter, then doing one of the following

1. Main Menu → Text → Inspect Character
2. Context Menu → Inspect Character
3. Keyboard shortcut: Command + Option + I

Using this, I can confirm that typing à̃ with the IPA keyboard results in the decomposed version, with three code points:

If I copy and paste this into a Bike code block, it doesn’t display correctly using the monospace font the app uses:

If I copy and paste it out of Bike and back to CotEditor, I can confirm that no normalization has occurred, and it still is the decomposed version using three code points:

The test I did was to paste the same letter from CotEditor into this website (https://unicodelookup.com), which also provides Unicode information for inputted text. Surprisingly, this does perform some normalization, and it says that it’s now partially precomposed. The a and ̀ (Combining Grave Accent) have been normalized to the precomposed à Latin Small Letter a with Grave), while the Combining Tilde has been left decomposed:

If I copy the letter that I had originally pasted in the input box on the Unicode Lookup and then paste that back into CotEditor, I can confirm that just pasting into Safari has performed the normalization:

I’ve tried pasting the same decomposed version from CotEditor into input text boxes on multiple websites in Safari, and then copying and pasting it back to CotEditor, and, so far, the normalization is always performed.

Interestingly, typing into the input box on the Unicode Lookup website actually results in the site reporting the decomposed version:

You can also see in the screenshot that the font they’re using in the input box displays the decomposed version incorrectly.

If I copy and paste the typed, decomposed letter from the input box on the website into CotEditor, I can confirm that no normalization occurs in CotEditor:

Next, I tried pasting the partially precomposed version (remember, it ends up being two code points) from Safari or CotEditor into a code block in new, blank Bike document, and the monospace font displays it more correctly (the line height might be off, but it’s definitely better):

If I copy and paste that from Bike to CotEditor, I can confirm again that no normalization takes place, and it remains two code points:

Next, I discovered something a bit surprising given the results so far: If I paste the partially precomposed version into the code block in the first Bike document that already contains the decomposed version, Bike then displays the decomposed and precomposed characters in the same way.

I can confirm that no normalization occurred by copying and pasting the originally decomposed version from Bike back into CotEditor:

The precomposed version that was pasted in the video also does not undergo any normalization in Bike, which can be confirmed by copying and pasting it back to CotEditor:

At this point, I asked, what happens if I paste the decomposed version into the second document hat has only the precomposed version. The same thing happens, the characters display correctly, and I can confirm by copy and pasting into CotEditor that now normalization takes place.

Sorry for the long post. I’m not sure what that means for Bike.

If you type à̃ using the IPA keyboard in CotEditor, does the inspector show that it is the decomposed version? Does pasting that letter into Bike display correctly on your machine? What about the partially precomposed version?

It would also be interesting to see how things are displayed when the bug for typing decomposed characters is fixed. Will it display incorrectly at first and then be fixed in some way after pasting or typing a precomposed character.

One last test I did was to change the main font for Bike to a monospaced font (Libertinus Mono) and try it without using code blocks. As you can see, the decomposed version appears much more like the precomposed version, nearly identical if not completely so.

So, different fonts do display better, at least in certain circumstances. So I think long-term, being able to set the font in a stylesheet or by other means would be helpful.

At this point, being able to type the decomposed characters directly in Bike would be most useful, and might make the font problem less of an issue.

Thanks again for all the work you’ve put into such a great app, and for taking the time to explore this issue with me.

[jessegrosjean]

@kc1

Sorry for the long post. I’m not sure what that means for Bike.

No way! It’s been great reading, thanks so much for all the investigation and explanation!

@kc1

If you type à̃ using the IPA keyboard in CotEditor, does the inspector show that it is the decomposed version? Does pasting that letter into Bike display correctly on your machine? What about the partially precomposed version?

Yes, I can reproduce everything you are describing now. The main issue was that instead of @1 I was using @^ and Bike didn’t seem to have problems with that accent.

@kc1

At this point, being able to type the decomposed characters directly in Bike would be most useful, and might make the font problem less of an issue.

I think I’ve got this working now in my local copy. Will release an update next week.

@kc1

Thanks again for all the work you’ve put into such a great app, and for taking the time to explore this issue with me.

Thanks for helping me understand what’s happening.

[jessegrosjean]

@jessegrosjean

Yes, I can reproduce everything you are describing now. The main issue was that instead of @1 I was using @^ and Bike didn’t seem to have problems with that accent.

I don’t know what I’m talking about, now it seems like I can reproduce problem with @^, I think maybe I was forgetting to using monospace font in some of my tests. Anyway I see problem now

[complexpoint]

@kc1

being able to type the decomposed characters directly in Bike

I should have noticed this too. I’ve been pasting material with Hebrew niqqud vowels, but never before tried to type them directly in Bike (typical typing doesn’t use them).

It turns out that adding niqqud to Hebrew consonants provokes the same problem in Preview (91).

[kc1]

Thanks for the update. Sorry for the delay in responding. I’ve been sick over the weekend, but I’m hopefully getting back into the swing of things.

That’s great to hear about the typing part.

@jessegrosjean

I don’t know what I’m talking about, now it seems like I can reproduce problem with @^ , I think maybe I was forgetting to using monospace font in some of my tests.

I just tried with @^ this morning and it worked every time. I’m note sure. I checked on the Unicode Lookup website, and one difference might be that ẫ can be normalized to one code point: LATIN SMALL LETTER A WITH CIRCUMFLEX AND TILDE U+1EAB instead of two. I’m not completely sure, but I think fonts can do different things in combining glyphs to render characters. But I don’t know too much.

Thanks again for your help!

[jessegrosjean]

@complexpoint

I should have noticed this too. I’ve been pasting material with Hebrew niqqud vowels, but never before tried to type them directly in Bike (typical typing doesn’t use them).

Another affect of this work is those niqqud vowels will stop getting clipped incorrectly as long as you have a big enough line hight multiple set.

[jessegrosjean]

I think many of the problems brought up in this thread (still no way to change monospace font) are now fixed in the latest Bike preview release:

Sorry I was confused on content of this thread. What was fixed is now you can type uncomposed diacritics without crashing. It’s also less likely that diacritics will get clipped… if they are still getting clipped you should be able to fix the problem by choosing a bigger line height.

There still are problems caused by the font. Thinking about that.

Bike 1.7 Preview (92)

Changed to wavy spelling, grammar, and correction underlines Changed to flash instead of slide caret for text replacements Fixed view update when learning and ignoring spelling errors Fixed crash when typing word breaking character mid-word Fixed crash when pasting text that matches existing text Fixed crash when inserting combining characters Fixed drawing to better include diacritics I still still need to fix bugs in the code that adds/removes/updates spelling and grammar underlines… This r…

Please try it out and let me know if there are still related problems.

[kc1]

Hi again. Thanks for all the great updates! I was wondering if you’ve thought any more about possible ways to use custom fonts for code blocks (I’m still mostly thinking about the issues described above in this thread when rendering decomposed stacked diacritics with the default monospace font …which I assume is still .AppleSystemUIFontMonospaced-Regular?).