The ink traps in IA 735 are pure ugliness at large font sizes. They're totally unnecessary unless you're printing with actual ink!
In search of the perfect writing font
51–60 of 60 posts
Re: In search of the perfect writing font
#52The ink traps in IA 735 are pure ugliness at large font sizes. They're totally unnecessary unless you're printing with actual ink!
For those that might be confused by what I mean: https://en.wikipedia.org/wiki/Ink_trap
Re: In search of the perfect writing font
#53Earlier quoted context omitted.
a lovely example is uFDFD, ﷽ (single char)
I am referring to Annex #11 (East Asian Width) of the Unicode Standard, which is all about CJK. Under those rules, U+FDFD is one column wide. If you happen to see it rendering really wide in the middle of text set in a monospaced typeface, it’s probably because a fallback font is being employed. In one arrangement locally I see it as eleven-and-a-bit columns, because it’s using it from another font; in another which…
My terminal displays it just fine, so it must be in at least one of the bitmap monospace fonts that I have configured it with.
Re: In search of the perfect writing font
#54I used to tell myself I couldn't code or write without the perfect font. I'd spend hours looking for it, and end up not getting any work done. When I finally did get around to actually working, five minutes in and I'd forget about the font completely. I have a (rather lazy) friend who's been asking me to help him start a blog for years now. I've promised to after he produces his first block of content, and he keeps s…
I keep searching for the perfect coding font. And I keep coming back to the classic VGA 8x16.
I don't know what it is about it, but it just looks right.
(It probably has a lot to do with the date of my birth, but then again... who cares why something feels right, when it does?)
Re: In search of the perfect writing font
#55Earlier quoted context omitted.
That’s why all my blog content resides in dropbox. One text file in the right place, and boom! A new post.
What do you have this implemented with?
Re: In search of the perfect writing font
#56Earlier quoted context omitted.
I am referring to Annex #11 (East Asian Width) of the Unicode Standard, which is all about CJK. Under those rules, U+FDFD is one column wide. If you happen to see it rendering really wide in the middle of text set in a monospaced typeface, it’s probably because a fallback font is being employed. In one arrangement locally I see it as eleven-and-a-bit columns, because it’s using it from another font; in another which…
My terminal displays it just fine, so it must be in at least one of the bitmap monospace fonts that I have configured it with.
That doesn’t mean it’s being rendered monospace.
(When herein I say “terminals” I mean “terminals/renderers/text editors/things like that”.)
Some terminals are truly monospace, simply not drawing glyphs that aren’t available at the right size (e.g. xterm).
Some terminals don’t actually care about being monospaced all that much, and are quite happy to handle glyphs of differing sizes, though up/down movements may still be character-based (e.g. Notepad++).
Some terminals try hard to both be monospaced and show you useful stuff, and will either horizontally truncate the glyph, or draw subsequent glyphs on top of any overflow (e.g. gVim).
Some terminals simply make a total hash of it, with the cursor positioning being monospaced, but drawing subsequent characters after the incorrectly-wide glyph (e.g. Ace).
Your example of U+FDFD is bonus fun because it’s RTL. Most terminals don’t handle RTL at all well. (Terminals capable of proportional rendering such as Notepad++ and plain old Notepad are much more likely to treat it properly in my experience.)
Re: In search of the perfect writing font
#57Earlier quoted context omitted.
My terminal displays it just fine, so it must be in at least one of the bitmap monospace fonts that I have configured it with.
That doesn’t mean it’s being rendered monospace. (When herein I say “terminals” I mean “terminals/renderers/text editors/things like that”.) Some terminals are truly monospace, simply not drawing glyphs that aren’t available at the right size (e.g. xterm). Some terminals don’t actually care about being monospaced all that much, and are quite happy to handle glyphs of differing sizes, though up/down movements may stil…
Yes it does. I wrote the terminal program. I know what it does with fonts.
Re: In search of the perfect writing font
#58Earlier quoted context omitted.
That doesn’t mean it’s being rendered monospace. (When herein I say “terminals” I mean “terminals/renderers/text editors/things like that”.) Some terminals are truly monospace, simply not drawing glyphs that aren’t available at the right size (e.g. xterm). Some terminals don’t actually care about being monospaced all that much, and are quite happy to handle glyphs of differing sizes, though up/down movements may stil…
Yes it does. I wrote the terminal program. I know what it does with fonts.
I’m curious: how many columns is it occupying? From all that I can see, it should be a single column, with the font incapable of overriding that.
Re: In search of the perfect writing font
#59Earlier quoted context omitted.
Yes it does. I wrote the terminal program. I know what it does with fonts.
I’m curious: how many columns is it occupying? From all that I can see, it should be a single column, with the font incapable of overriding that.
I can tell you that terminal emulator is finding the character in the fonts that I have configured it with. But it won't tell you the stuff about character widths that you want to know, I suspect.
As I mentioned, my terminal emulator uses bitmap fonts. Whilst bitmap fonts do have a mechanism of specifying either single-width or double-width characters, it ignores that and displays everything in the same width, rescaling everything with some slight special-casing of block graphic and horizontally repeatable characters. So whilst by the looks of the amount of detail in the glyph on screen, U+FDFD is a double-width character in the font file; it occupies a single column.
See the "Fonts" section of http://jdebp.eu./Softwares/nosh/guide/console-fb-realizer.ht...
I am currently using a mixture of monospace bitmap fonts that I have obtained from various places:
--vtfont-normal-i fonts/t0-16i-unicode.fnt --vtfont fonts/9x15.fnt --vtfont fonts/k16-1990.fnt --vtfont fonts/unifont-7.0.06.fnt
Re: In search of the perfect writing font
#60Earlier quoted context omitted.
I recently converted my dynamic DB-driven blog to a static website. I did not predict how badly the added latency between having an idea, writing down the first flawed paragraph, saving a draft, reading what I wrote, then revising and publishing would reduce my writing output. Sure, I can write in Google Docs, but because it's not on my site one click away from being "out there" I am far less compelled to write down…
I had the opposite feeling. I wrote my PhD thesis in 1998-2000 and the editor of choice at the time was Word. It was a pain to deal with the formatting, spacing, page breaking and other -ings. I then tried LaTeX and all problems vanished. Since I could not influence the output (at least without a lot of work) I simply gave up and started to "code my text". It was way faster than admiring my artful working all the tim…
Markdown is a must. I used it on dynamic blog and on my static site, but I paid less attention to my writing when posts were not "live".
I believe that Bret Victor's Inventing on Principle concept of minimising the time between having an idea and seeing a change universally applies to every user kind of interface.