Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python: font.generate not outputting glyph data to BDF #5033

Open
projectitis opened this issue Jun 1, 2022 · 6 comments
Open

Python: font.generate not outputting glyph data to BDF #5033

projectitis opened this issue Jun 1, 2022 · 6 comments
Labels
bite-sized I-bug scripting workaround-available A workaround, described in the thread, is available.

Comments

@projectitis
Copy link

I am loading a TTF font, generating bitmap strikes, then saving as BDF.
The resulting BDF file has the header data, but does not contain any glyphs.
I assume I am using the generate command incorrectly, but the docs there are extremely light.

This is a cut-down snippet of my script:

font = fontforge.open('KiwiSoda.ttf')
font.bitmapSizes = ((output_size,),)
font.regenBitmaps((output_size,))
font.generate('KiwiSoda.bdf', bitmap_type='bdf', bitmap_resolution=72)

If required, the original TTF and the generated BDF are attached: kiwisoda_ttf_to_bdf.zip

  • Windows 11
  • FontForge 20220308
  • ffpython
@projectitis
Copy link
Author

ok, immediately found the cause: The font has to have a selection. The selected glyphs are included in the generated BDF.

font = fontforge.open('KiwiSoda.ttf')
font.selection.select(('ranges',None)," ","~")
font.bitmapSizes = ((output_size,),)
font.regenBitmaps((output_size,))
font.generate('KiwiSoda.bdf', bitmap_type='bdf', bitmap_resolution=72)

Will close this issue, and leave the solution for posterity!

@ctrlcctrlv
Copy link
Member

Reopening as it's not documented in font.regenBitmaps that the selection is taken into account.

@ctrlcctrlv ctrlcctrlv reopened this Jun 1, 2022
@ctrlcctrlv ctrlcctrlv added I-bug scripting docs bite-sized workaround-available A workaround, described in the thread, is available. labels Jun 1, 2022
@projectitis
Copy link
Author

Note: I'm not sure if it's font.regenBitmaps or font.generate that requires the selection.

@ctrlcctrlv
Copy link
Member

Don't worry, I'm sure enough for both of us.

The call tree looks like font.regenBitmapsPyFFFont_regenBitmaps (python.c) → bitmapper (python.c) → BitmapControl (fontforge/bitmapcontrol.c) → BitmapsDoIt (fontforge/bitmapcontrol.c) → FVRegenBitmaps (fontforge/bitmapcontrol.c), which checks selection status:

if ( fv->selected[i] || bd->which == bd_all ) {

@ctrlcctrlv ctrlcctrlv removed the docs label Jun 1, 2022
@ctrlcctrlv
Copy link
Member

I removed [docs] tag as this is just a bug, the selection reliance does not look intentional.

@clort81
Copy link

clort81 commented Jan 15, 2023

  • I open a bitmap font. I want to add a glyph to an empty code point.
  • I click on a source glyph and copy (ctrl-c).
  • I click on the destination code point in the table that I want to create a new glyph for.
  • I paste (ctrl-v).
  • I double click the new glyph and can edit. It inherits all the correct properties from the source glyph, so far, so good.
  • I finish editing, close the window.
  • The new glyph still has a faint 'x' in it, like unedited/empty glyphs do.
  • The new glyph isn't exported to a .bdf file when i generate a font.
    why_are_there_Xs

Why?
If I create a new glyph, I logically expect Fontforge to understand that I want the font to include this glyph.
I logically want the font I export to include the new content I added.
Is this a bug?? Or a feature request?
[EDIT] it's only happening with this font. It might be a different problem.
Blapinus4Medium.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bite-sized I-bug scripting workaround-available A workaround, described in the thread, is available.
Projects
None yet
Development

No branches or pull requests

3 participants