by LoganDark

Download disabled

The designer of this FontStruction has chosen not to make it available for download from this website by choosing an “All Rights Reserved" license.

Please respect their decision and desist from requesting license changes in the comments.

If you would like to use the FontStruction for a specific project, you may be able to contact the designer directly about obtaining a license.

This is is the most accurate HD44780 font you can find on FontStruct, because it has pixel-perfect representations of all 190 original characters (not including 0x00-0x0F, which are impossible on FontStruct)

0x00-0x0F are mapped to 0x100-0x10F since I can't add characters before 0x20.

Info: Created on 11th November 2017 . Last edited on 13th November 2017.
License Creative Commons
Fave Tags:
  • -


The grey characters are implemented pixel-perfect in the font, and the black (or empty) characters are missing. The empty characters are supposed to be missing on both the HD44780 itself and the font, but due to FontStruct limitations I can't make those missing characters as wide as the others, so I replaced them with spaces.

I don't know how to fix the missing characters, but 0x7F and 0xAD are actually viewable in the FontStruct editor (either the downloaded font or Sketch just doesn't like it). Due to FontStruct (and maybe TTF) limitations, it is impossible for me to add 0x00-0x0F to the font.

Comment by LoganDark 11th November 2017

So, we shall see if somebody can clone "HD44780" to fix this set of characters. As it, it's already very good (the original design is quite crisp and coherent - a standard 5x7 with non-Latin glyphs).

Comment by dpla 11th November 2017

I can confirm the 'missing' 0x7F and 0xAD characters are in the font, Sketch just chooses to be weird with them.

Comment by LoganDark 11th November 2017

Maybe you can put them outside of 00-FF range???

Comment by anonymous-1466233 11th November 2017

I might have misunderstood: any screenshot of the visible 0x7F-AD chrs in the fontstructor, LoganDark?

Comment by dpla 11th November 2017

It's not a range, those are two individual characters that Sketch just chose to treat weirdly - probably because soft hyphens only appear when there's a line break, and 0x7f is literally the DELETE character.

@xxx-xbox-gamer-xxx I'm trying to make this font as accurate as possible, although I could put 0x00-0x0F outside 0xFF (edit: they're now placed beginning at 0x100)

0xFE not being as wide as it should be (and actually not even included in the font like it should be!) can't be fixed, at least not that I know of

Comment by LoganDark 11th November 2017

Here's all the characters from 0x20 to 0xFF. You can see at the bottom right one of the characters is missing (it's supposed to be blank, but the font doesn't even include it)

Comment by LoganDark 11th November 2017

Ah, OK, I misread or overlooked in haste again, sorry.

• Of course, no regular/modern (>1990s*) font whould display the 0x00-1F control characters (if it was your concern in the exported file). {* I did not know, but Wikipedia confirm it's old specifications for 1987.}

• The same (Iso > Unicode) legacy applies to the 0x7F DEL control character (for the same reason, while this character were often made visible at that time, for the extreme lack of mapping in less than 7 bits (95 visible characters, Space included, thus many proprietary or/and local hacks, like 3 characters in your case, US-ASCII-wise)).

• 0x80-9F are control characters for the second range of (now) Unicode (they are thus invisible).

• 0xA0 and 0xAD should remain invisible (but again, if your controller added a glyph, transitory or not, the TTF disapproves this hack, then you have to map elsewhere - your final software/renderer will have to restore the code points, e.g. via a simple corrective array of hex values).

• All the invisible characters (controls and spaces) can be made visible if you add a thin layer of software (the Unicode added a dedicated range that you might copy if you disapprove the blanks, even many decent word processors use character substitutions pertaining to -at least- three 'invisible but non-control characters' (namely 0x20, 0xA0, 0xAD if we limit to your controller)).

• I still don't know/use (Arduino's) Sketch, thus I cannot be helpful about its support of the LCD controller glyphs in question (e.g. any unexpected behaviour), sorry again, it's probably not the right 'forum' to ask (or look for old school coders).

• Wikipedia specifies the related font: “The Hitachi HD44780 […] includes […] and some [UNSPECIFIED] symbols in two 28 character lines”. I don't know, but if the unspecified characters were not documented, this has no simple solution. Your TTF font (= software) tries to mimic “the HD44780UA00 [ROM], the standard (Japanese) version”. You development H/W being different today, unavoidable incompatibilities occur, I assume. (Virtual sandboxes or any recommended emulation might not help completely.)

• On our very limited TTF format, we cannot decide a lot of features. When we cannot map at the right location, we have to map at another one… (Say 'goodbye' to Unicode in this situation! choose the ranges / code points you prefer, not too bit-demanding, though…).

• The same multipurpose encyclopedia states it's a 5x8 (not 5x7 as I believed from a modern standpoint). Therefore, the line height (extra line of blank pixels) might be 'hard coded' physically… I think you copied this design with your baseline (via the automatic addition by the fontstructor).

These mapping concerns are not at all specific to your hardware (old ROM).


Now, another issue you told us, was about the width…

This time, I assume you may want to unlock your monospace design, for a 'handsfree' design of all your (visible) glyphs. (Just move the dedicated vertical line in the fontstructor, glyph after width. You can multpliply the basic square size etc. for more precision etc.)
So that at the end, your proportional font will not be tagged 'Monospace', but it'll look mono on the glyphs you decided individually (even look wider as monospace on the characters you need, e.g. in 0xFE as you mentioned).

Comment by dpla 11th November 2017

Ummmmm... Arduino has nothing to do with this. I mean Sketch as in sketchapp. Sorry for the confusion.

Comment by LoganDark 11th November 2017

Ah, I see… MODERN frameworks vs. OBSOLETE hardware…

Comment by dpla 12th November 2017

Read the rest.

Comment by dpla 12th November 2017

What exactly are you trying to solve with your comment?

Comment by LoganDark 12th November 2017

The impossible exact mapping + the possible exact width, for instance.

Comment by dpla 12th November 2017

If you know all about Unicode and s/S/W dev, you can ask on the dedicated sites.

Comment by dpla 12th November 2017

Thanks, but no thanks.

Comment by LoganDark 12th November 2017

So there's no solution for your mapping (do your best -as you did- to provide the most accurate TTF version + a doc that explains the defects), but I think/thought your issue about the width was a lack of training in fontstructing(?).

Bye! (my final word).

Comment by dpla 12th November 2017

Yes, the issue about the width is a problem with my ability to use FontStruct. I believe there might be some feature somewhere that allows for blank characters.

The mapping is a (hard to solve) issue, I worked around it by relocating the first 16 characters to a space outside the normal range, and specifying which characters moved to where.

Comment by LoganDark 12th November 2017

Looks like I've got a solution. Testing it now.

Comment by LoganDark 13th November 2017

Also of Interest


Get 10% off the world’s leading font editor for OSX.

More from the Gallery

HD44780by LoganDark
Unevenby LoganDark
TI-83+by LoganDark
Brikdby geneus1
French Defenceby Frodo7
Murtby architaraz
fs Alhambraby William Leverette (will.i.ૐ)
zandalo eYe/FSby elmoyenique

From the Blog


Vertical Metrics, Improved Touch Support and More


Future Competition Results


Competition: Future


New Bricks: Square Connectors