has anyone ever made a USABLE number font in the size range from 25-30 pixels of height?
all fonts in u8glib in that range have different heights for the numbers 0-9, they are never aligned in height
and the format only has a windows converter which is quite inconvenient -.-
Made some pics of the problem:
the one and five sit one line lower than 3 and 0
the one is one line lower -.-
and here the 7 is one line less high than the 3s and 0
I encountered the same issues as you but when I understood a little more about fonts and the conversion process I found this is (in most computer applications) the norm. Fixed width fonts (and perhaps height) don't typically reach a large size. I wanted fixed width and height so I converted and modified my own. It's about 30 pixels high and from memory 28 pixels wide and only includes numbers. My application was for a GPS clock.
For the discussed number fonts, i have used the following conversion process:
Convert (scale+raster) truetype font into a bdf font. Result is a .bdf file. Tool: otf2bdf
Convert .bdf file to a .c file (internal u8glib format). Tool: bdf2u8g
Misalignment already appears in step 1. To fix this, either add information to the original .ttf file or update/fix the intermediate .bdf file. I am always happy to update, fix or add fonts. Just send me the related .bdf or .ttf files.
I'm really stoked you guys are doing this! I took a look and was a little intimidated by the process of making my own font and converting it, as I know almost nothing about fonts. (Also FontForge crashes on my computer.)
koyaanisqatsi:
I took a look and was a little intimidated by the process of making my own font and converting it, as I know almost nothing about fonts. (Also FontForge crashes on my computer.)
Thank you!
FontForge is definitely the way to go… but I am also a bit noobish in using it.
I cannot for example, get into bitmap mode from an empty font… I have to import another existing bitmapfont and work from there on -.- which is kind of annoying… but it works.
If you have it in bitmap mode… it is VERY easy to create a pixel perfect bitmap font
I am using a selfcompiled version of FontForge on MacOS X
@olikraus
the new fonts are also copyleft (public domain) as the other too… I think that I will never do a copyrighted/limited/unfree font
HA HA, I have prevailed! FontForge is now running in Ubuntu in a VM (the version available in Ubuntu is kinda old, but it works fine so far). And I think I might be getting the hang of this.
I found how to make bitmap fonts from a new/empty font:
Start a new font
Element -> Bitmap Strikes Available...
Choose "X" and specify a pixel size (height)
When you edit a glyph, it should edit in bitmap mode. If not, then Window -> New Bitmap Window, and then close/minimize the outline window.
Will be trying out dbf2u8g.exe in the next few days.
Now if only I had an idea on how I want the font to look...
I pushed my wor to gihub, including my started PCB/schematics
I am still struggling with the license I should use… U8Glib is BSD style… so basically anything is fine… but the DallasTemperature library is LGPL and I do not know in what aspects that is limiting my options ahhrg LicenseWars
This is my personal interpreation about the difference between LGPL and BSD License:
LGPL is more strict and requires that the user can rebuild the complete project which makes use of the LGPL Software. It must be possible to rebuild the complete project with an updated version of the LGPL part. In the case where your complete software is available on github or similar platforms, than this difference does not matter.
However you need to inform the user about the different parts and licenses of your software.
For example, have a look at the u8glib license: Google Code Archive - Long-term storage for Google Code Project Hosting.
U8glib does not have a single license. Each font might have a different license with different requirerments.
Depending on the font, which are used in your project, you might need to give proper reference.
I downloaded this library a couple days ago and am having a blast with it! It is the most comprehensive and flexible display library I've seen.
However, I'm having a bit of trouble doing some simple stuff.
I'm basically trying to get my screen to plot the input of the ADC; a line over time, sort of like the way an oscilloscope scans when the time/div is big enough. Or how an EKG display refreshes (which is what my application is.) I was previously doing this with a generic parallel GLCD using the GLCD library. Here's how I was doing it:
#include <glcd.h>
int xPos = 0; // X position value.
int pot; // Potentiometer value.
void setup()
{
GLCD.Init();
GLCD.ClearScreen();
}
void loop()
{
for(xPos = 0; xPos < 127; xPos += 1)
{
pot = analogRead(A0); // Sample ADC
pot = map(pot, 0, 1023, 0, 63); // Scale down readings to LCD's vertical pixel count.
GLCD.DrawVLine(xPos, 0, 63, WHITE); // Erase column of pixels previously set.
GLCD.SetDot(xPos, pot, BLACK); // Set new pixel.
delay(10);
} // End FOR statement.
if(xPos == 127)
{
xPos = 0; // Return to the first column when the last column is reached.
} // End IF statement.
} // End void loop()
I changed this to fit the profile of this library by doing away with the For loop and fitting it in a Do While, changing the functions, so on. (I'd post it, but it appears that I didn't save it :~ ) It of course doesn't work since this library (to my understanding) rewrites the entire screen each time it cycles rather than just the pixels specified in the functions. Instead, it just scans a single pixel.
I guess what I'm asking is for some insight on how I might be able to get this library to continuously draw without necessarily rewriting the entire display, if that's possible in the first place.
If I must rewrite the full display, I guess I could store all 128 columns in an array and write them all over every time I refresh. I'm not sure how efficient that is, though.
If I must rewrite the full display, I guess I could store all 128 columns in an array and write them all over every time I refresh. I'm not sure how efficient that is, though.
This is correct. You must store the 128 values in order to be able to refresh the display. It is indeed the key difference between u8glib and GLCDv3. For sure this makes u8glib slower than GLCDv3, but this enables u8glib to support displays where the display frame buffer can not be read back from the display (and still avoid a local full frame buffer).
First, thanks for this great library!
I just tested a LM096-128064 (128x64 OLED; SSD1306) with a atmega168 and it works flawless.
Is there a chance, that in a future version, the picture loop philosophy can be activated / deactivated for drawing graphs.
I am facing the same problem as Muhammad in the last posting.
Background:
There are GLCDs were the internal frame buffer (display memory) can not be read by the microcontroller.
This is usually true for displays with SPI interface.
Solutions:
Reserve memory in the microcontroller, render the picture into it and transfer the memory from the microcontroller to the display.
Disadvantage: Large SRAM consumtion, possible only if display frame buffer size is smaller than the available SRAM.
Reserve some smaller amount of memory (e.g. 1/4 of the display frame buffer size) and render the picture more often (e.g. 4x). This trades time vs. SRAM
Disadvantage: Slower frame rate, picture loop (more complex API)
U8glib was designed to support displays without read back ability.
U8glib follows solution 2)
U8glib is one of the view libs which support large SPI displays on small (ATTINY) controllers (with very limited SRAM).
A graphics lib such as GLCDv3 for KS0108 controller has a much more convinient programming interface. But GLCDv3 also depends on the fact that it can read memory from the display frame buffer.
U8glib offers a solution for displays not support by other graphics librarys.
U8glib sometimes is the only available lib.
U8glib might be a bad choice in other cases (like using it for KS0108 based displays)
I am glad to hear about success stories with U8glib and i am sorry to offer programming API, which is more complicated and difficult to understand.
I tried to compensate this with many features, a good collection of fonts, reliable functions and a documentation with many pictures.
I am always open to improvements, but i probably can not change its basic feature.
I also suggest to read Bill's remarks on GLCDv3 and u8glib: