linebender / runebender Goto Github PK

I would like to propose adding some VCS integration on a first-class basis — not to make the font editor a full Git client of course, just to facilitate the bits where the font editor has more idea what is what than a third party generic VCS app would.

First detect whether the file being edited is also tracked in Git. If not, nothing changes. If so, add some options.

• A "commit" option along side save that would save, stage, and commit the relevant UFO files. An extra check should probably make sure the rest of the repository status is clean before enabling this and show the feature disabled if the cache has anything in it.

• Add a "revert" option that is basically an aggressive undo that backtracks to the last committed version. Perhaps this would function by stashing the current change, then resetting the file.

• Add comparison functions such as a glyph editor background that shows a greyed out outline of the last commited state of a glyph. The git object store can be queried directly for the last saved object.

More is certainly possible, but if VCS was brought in as a first class part of the tooling I think the overall workflow could be radically different (and better) than any other tooling that is out there.

If this is an agreeable proposition I'm even willing to help out a bit with some implementation work. I'm not much of a graphic designer but I do have a pretty deep understanding of how Git works and I'm just getting up to speed with Rust.

currently we categorically refuse to save any file that we did not create, with the rationale that our save operation is going to be lossy; there are parts of the UFO that we do not currently bother loading, and we only save what we've loaded.

This seems a bit zealous, though; it would make more sense to just refuse to save over a file we didn't create, but we should be okay with letting people do "save as" and creating a new file.

(see #178)

We need some sort of toolbar; a row or column of icons representing available tools, with the current tool indicated.

Currently we're trying to save in place, which means if we error at some point in the saving process we destroy data. We should try to save in a temporary location, and then move that to the final location when save succeeds.

when a glyph is selected (#76) we should show that glyph's metadata in the sidebar.

Adding, removing, renaming glyphs etc should all be undoable, and this should be tracked distinctly from how we track edits to individual glyphs.

When using Glyphs I can hold Option+click on an outline between two on-curve points to add new off-curve points. This is useful in many different ways and used all the time while drawing.

The Windows file picker can't "open" a .ufo as a file. Font editors on Windows commonly do "UFO package (*.ufo|metainfo.plist)" and then you click the metainfo.plist file. Note that you need to do path manipulation to toss metainfoplist out again to get the true UFO path.

This option could just be something in the paths menu with a label like "make selected node first".

This would be useful for a variety of reasons, but mainly it is important for variable fonts. If two paths have the same point structure, but different first segments, the interpolated in-between shapes will be twisted and unrecognizable.

Maybe I could figure out a PR for this using src/draw.rs/draw_direction_indicator as a starting point.

Sorry I don't know the correct term for this state of the pen tool but here is my process to recreate:

select the pen tool

1. click to draw one point
2. click to draw second point
3. click and drag while drawing third point to pull out a curve
4. let go of click (don't click again)
5. hit backspace

I get

thread 'main' panicked at 'index out of bounds: the len is 4 but the index is 4', src/draw.rs:195:30

When more than one point is selected, display the width and height of the bbox enclosing the selection points. Among other things, this is a very useful mini-measure tool.

The second stage of this feature would be making them editable labels, and having updates to them drive a scale transformation. But I think that's much less used. I'm inclined to implement mouse-driven scaling by dragging handles associated with the selection bbox first.

OS: Windows 10

Steps to reproduce:

1. Open runebender via cargo run
2. double-click any of the empty glyphs to open the editor
3. Right-click to open the context menu and immediately left-click anywhere on the canvas. It's importand that the mouse is moved a few pixels so you don't click on the border of the context menu, and it has to happen quite quick. You might have to try this a few times and really fast, but I also had it happen on first try.

Here's a screen cap showing it:
Desktop 2020.10.21 - 17.26.29.08.mp4.zip

And here's the full terminal output:

> cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.30s                                                                                                                                   
     Running `target\debug\runebender.exe`
DEBUG [druid::localization] available locales [], current en-US
DEBUG [druid::localization] resolved: [en-US]
DEBUG [druid_shell::platform::windows::window] dxgi factory pointer = 0x29769773100
DEBUG [druid_shell::platform::windows::window] 0x2976977c410: desc = Some("NVIDIA GeForce GTX 980 Ti"), vram = 6393823232
DEBUG [druid_shell::platform::windows::window] 0x29769778620: desc = Some("Microsoft Basic Render Driver"), vram = 0
DEBUG [druid_shell::platform::windows::window] adapter = 0x2976977c410
DEBUG [druid_shell::platform::windows::window] swap chain res = 0x0, pointer = 0x2976b7504a0
WARN  [druid_shell::hotkey] warning: HotKey HotKey { mods: Shift, key: Character("u") } includes shift, but text is lowercase. Text is matched literally; this may cause problems.
DEBUG [druid_shell::platform::windows::window] dxgi factory pointer = 0x29777353eb0
DEBUG [druid_shell::platform::windows::window] 0x29777354270: desc = Some("NVIDIA GeForce GTX 980 Ti"), vram = 6393823232
DEBUG [druid_shell::platform::windows::window] 0x29777354700: desc = Some("Microsoft Basic Render Driver"), vram = 0
DEBUG [druid_shell::platform::windows::window] adapter = 0x29777354270
DEBUG [druid_shell::platform::windows::window] swap chain res = 0x0, pointer = 0x297774d1e60
ERROR [druid_shell::platform::windows::window] dropped message 0x215, hwnd=0x53d2e, wparam=0x0, lparam=0x53d2e
ERROR [druid_shell::platform::windows::window] dropped message 0x2a3, hwnd=0x53d2e, wparam=0x0, lparam=0x0
ERROR [druid_shell::platform::windows::window] dropped message 0x205, hwnd=0x53d2e, wparam=0x0, lparam=0x1790289
ERROR [druid_shell::platform::windows::window] dropped message 0x215, hwnd=0x53d2e, wparam=0x0, lparam=0x0
ERROR [druid_shell::platform::windows::window] dropped message 0x2a3, hwnd=0x53d2e, wparam=0x0, lparam=0x0
ERROR [druid_shell::platform::windows::window] dropped message 0x205, hwnd=0x53d2e, wparam=0x0, lparam=0x13a026b
ERROR [druid_shell::platform::windows::window] dropped message 0x215, hwnd=0x53d2e, wparam=0x0, lparam=0x0
ERROR [druid_shell::platform::windows::window] dropped message 0x2a3, hwnd=0x53d2e, wparam=0x0, lparam=0x0
ERROR [druid_shell::platform::windows::window] dropped message 0x205, hwnd=0x53d2e, wparam=0x0, lparam=0x152023a
ERROR [druid_shell::platform::windows::window] dropped message 0x215, hwnd=0x53d2e, wparam=0x0, lparam=0x0
ERROR [druid_shell::platform::windows::window] dropped message 0x2a3, hwnd=0x53d2e, wparam=0x0, lparam=0x0
ERROR [druid_shell::platform::windows::window] dropped message 0x215, hwnd=0x53d2e, wparam=0x0, lparam=0x0
ERROR [druid_shell::platform::windows::window] dropped message 0x2a3, hwnd=0x53d2e, wparam=0x0, lparam=0x0
ERROR [druid_shell::platform::windows::window] dropped message 0x205, hwnd=0x53d2e, wparam=0x0, lparam=0x12c022c
ERROR [druid_shell::platform::windows::window] dropped message 0x215, hwnd=0x53d2e, wparam=0x0, lparam=0x0
ERROR [druid_shell::platform::windows::window] dropped message 0x2a3, hwnd=0x53d2e, wparam=0x0, lparam=0x0
ERROR [druid_shell::platform::windows::window] dropped message 0x205, hwnd=0x53d2e, wparam=0x0, lparam=0x12b0235
ERROR [druid_shell::platform::windows::window] dropped message 0x215, hwnd=0x53d2e, wparam=0x0, lparam=0x0
ERROR [druid_shell::platform::windows::window] dropped message 0x2a3, hwnd=0x53d2e, wparam=0x0, lparam=0x0
thread 'main' panicked at 'already borrowed: BorrowMutError', C:\***\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib/rustlib/src/rust\src\libcore\cell.rs:877:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\runebender.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)

This is probably too early, but i've found that on a Mac i need to call something like

export PKG_CONFIG_PATH="${PKG_CONFIG_PATH}:/usr/local/opt/libffi/lib/pkgconfig"

in order to make runebender compile. Otherwise i'd got

Package libffi was not found in the pkg-config search path.

while compiling cairo-sys-rs.

This is actually fairly tricky, because it requires us to provide UI for selecting the component to add from a list of available glyphs.

A first pass at this would maybe just be a text input field, which would validate on submit.

A simplish nicer option might be a dropdown list of available glyphs; and then there are fancier search-panel options beyond that.

I'm setting this as a goal for the alpha, but I'm willing to push it if it's too much work.

currently in the grid view when you click on a glyph it opens the editor. We should be able to select a glyph on single click, which will allow editing of glyph metadata, advance, kerning, etc.

At commit a001e77 on macOS running cargo run --bin ufo_editor ~/Desktop/MutatorSansBoldWide.ufo gives me the following error:
failed to run custom build command for 'cairo-sys-rs v0.7.0'

This was fixed by running: export PKG_CONFIG_PATH="/usr/local/opt/libffi/lib/pkgconfig" cargo build

How can this error be prevented from occurring?

Adding a guide to a glyph is cool, but in order to be useful I think the guides need to show up on all glyphs rather than just the one it was added too.

How we want to surface this sort of information is a fairly big design question, but at the very least it would be nice if we could see the actual coordinates of a point during editing.

we should have the ability to scale, rotate, and possibly flip (x/y) a selection.

This is on a Mac with TTFs from /opt/X11/share/fonts/TTF:

According to @raphlinus unitsPerEm needs to be respected.

Working with the same source as #177, hitting File→Save has the (unexpected) effect of deleting the UFO sources entirely. The console messages imply something else:

INFO  [runebender::data] saving to "sources/OstrichSans-InlineItalic.ufo/"
ERROR [runebender::app_delegate] saving failed: 'To prevent data loss, norad will not save files created elsewhere.'

If you can't save that's fine, but nuking files while claiming to prevent data-loss is a bad look ;-)

Hello, this looks like a very interesting project, would it be possible to add screenshots of how it looks currently to the README?

I am currently using the latest Git build as of an hour ago, but I actually noticed this weeks ago and never got around to reporting it.

It seems that any time I double click on the glyph canvas interface I get a panic like this:

DEBUG [druid::localization] available locales [], current en-US
DEBUG [druid::localization] resolved: [en-US]
WARN  [druid::menu] MenuDesc::platform_default is not implemented for this platform.
INFO  [druid_shell::platform::gtk::application] gtk: Activated application
WARN  [druid::menu] MenuDesc::platform_default is not implemented for this platform.
WARN  [druid::menu] MenuDesc::platform_default is not implemented for this platform.
thread 'main' panicked at 'assertion failed: prev.button != event.button', src/mouse.rs:299:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

GTK on Linux, Xorg.

One of the primary tools in a font editor.

FontForge has a useful metrics window for editing spacing, metrics, and kerning. Previewing text and testing how the font will look in different text string combinations is another use of this window. A tool of this kind is usually expected by users of font editing software.

RoboFont also has a window in this style, which last time I used RoboFont was called the "spacecenter."

When editing a glyph, we should invalidate all other locations where that glyph is used, such as in the grid view and in open glyphs where the changed glyph is a component.

Currently, styling decisions are hardcoded, but there has been some discussion about using TOML files for setting values relating to colors, lines, fonts, margins, etc. This way, the theme used for the UI can be changed easily, and users who are comfortable building from source can make custom themes.

I think it makes sense to do this sooner rather than later so that replacing hardcoded styling decisions doesn't become a difficult task.

The initial themes could just be a light and dark theme.

currently copy copies all paths (and only the paths) in the current edit session.

ttf-parser is a font-rs alternative (at least right now, runebender uses it only for glyph outlining). Unlike font-rs, ttf-parser has a wider set of features. Mainly the CFF support. It also a bit faster and heavily fuzzed.

one of the other primary tools for a font editor.

This might get cut from the initial release, but it should definitely be an early feature.

The Libre Graphics Meeting 2020 is happening at the end of May in Rennes!

As usual, the first conference will be the State of Libre Graphics, where we will give an overview of what has happened during the last year in the world of Libre Graphics.

You're very welcome to submit two slides for your project. They will be presented by the moderator of the State of Libre Graphics.
Instructions for submitting the slides can be found in the Github repository that will contain all slides:

https://github.com/libregraphicsmeeting/state-of-lg-2020

If you have further questions, don't hesitate to open a ticket in the same repository.

And, of course, you're very welcome to join us in Rennes!

Also fairly important. this will involve a bit of work in norad, to allow creation of layers and adding of glyphs to layers; it also requires a bunch of work in the grid view to allow things like changing the name of a glyph.

Some recent set of changes added a filter option to the GTK File Open dialogues, and the app is now looking to open things that it understands. I assume it is looking for UFO 'files'. The problem is UFOs are not files, they are a directory structure! As such I can find them in the chooser, but when I hit "Open" it just opens the directory in the chooser and never actually opens them in the app. I can't open an UFO at all through the dialogue, the only way I can open a UFO now is to launch the app passing the UFO name as the first argument.

As a first step, I would like to implement save only for files created by runebender; files created by other tools can be viewed but not saved.

I just tried to add a name to a UFO font and discovered that I could hit "edit" and type seemingly anything I wanted in the name field except a lower case 'h'. Uppercase was fine, other letters were fine, and I could paste an 'h' into the field, but I couldn't type one. It just ignored me.

Linux / GTK

the command gets handled in the wrong place

This is at least the case on macOS. I imagine this is a druid issue, but I'd like to track it here as well.

I just tried to have a look at the sources for Ostrich Sans Inline Italic and noticed several glyphs look different in the preview that the actual shapes warrant:

currently editing via the numeric fields modifies glyph data via a lens, without going through the Editor struct, where undo state lives. This means it is more or less invisible for the purposes of undo.

It seems visual studio code estabilshes if a font can be used
by checking if the bounding box of 'i' = 'w'. If they're the same width then it will let you code with it.

Coding fonts is probably a big target market. Would be good to be able to check if a font meets the vscode criteria, and also maybe a way to force the widths to all be the same? (I've handmade audiowide mono with font forge so the widths are fairly monospaced, but font forge crashes on me so often it's hard for me to work with it anymore.)

On macOS with commit a2045c0 I'm not able to get Arabic text strings to render in the UI.

currently this is alphabetical by name; the ideal solution would probably use something like unicode character database properties to sort by script, or block, and then in some well-defined order within those groups.

An acceptable temporary solution, to me, would be to sort by codepoint.

Seeing updates merged in #155 I rebuilt and tried to run on Linux.

I fired up a UFO (one that I'd just tested with the other day and was still in my command history) and double clicked on glyph. PANIC.

thread 'main' panicked at 'index out of bounds: the len is 16 but the index is 16', src/draw.rs:206:30

Opening it back up and trying a few more, it seems about half of the glyphs in this particular file cause panics if I try to open them, the other half are okay. It would be a strange coincidence if testing the other day I managed not to land on any of the crashy glyphs.

specifically 'save as' should change to 'save'

A common font editor feature is to report "side bearings", which is the inset from the advance to the bounding box. To display these, use the kurbo bounding box feature on the path. Lens update is slightly trickier. The right side bearing functions much as lensing the advance, but updating the left side bearing does a nudge of all points in the glyph, as well as the advance.

This would be added to the current advance display in sidebar, but I think it would also be useful to have a metrics mini-panel on the same row as the coord pane. That could be a separate issue though, as it's UX polish rather than core functionality.

I should also point out that doing fitting using side bearings "by the number" is a bit of an antipattern, but that's just for information. An extremely common use case is "this needs 10 more units on the left".

I have to Ctrl+C the process.

Figure out a good name for this operation ...