Would it be possible to have a setting to customize which font is used for code blocks that is separate from the main font?
Eventually maybe, but I donāt think I want to do this yet. Seems like a pretty specific preference, and I think maybe it would be better handled with stylesheet. Is there a function, reason this is needed or just a visual preference?
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!
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 
1 Like
Bike is using the system defined monospace font. On my macOS Ventura computer that is resolving to a font named: .AppleSystemUIFontMonospaced-Regular
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Ć Ģ ɔūĢmaĢĢ mĆ¹ĢhmĆ¹ĢŹ into a code block in Bike?
Thanks again!
This is what I see after āReset Typographyā in Bike Settings on macOS 13.0.1 (22A400):
What version of macOS are you using?
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!
Which apps? Iām trying TextEdit and Pages, but so far am not seeing the problem
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.
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. 
That makes sense.
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:
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!
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.
1 Like
Thanks! I think the stylesheet option would be more than adequate.
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!
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: aĢĢ, 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
- Main Menu ā Text ā Inspect Character
- Context Menu ā Inspect Character
- 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.
1 Like
No way! Itās been great reading, thanks so much for all the investigation and explanation!
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 think Iāve got this working now in my local copy. Will release an update next week.
Thanks for helping me understand whatās happening.
1 Like
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
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).
2 Likes
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.
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 aĢĢ 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!
1 Like
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.
1 Like