For copying and pasting points and splines

82bf6a5

File

{
  "layers": [
    {
      "name": "Layer 0",
      "visible": true,
      "color": null,
      "outline": [
        {
          "inner": [
            {
              "x": 125.285736,
              "y": 197.28552,
              "a": {
                "At": [
                  119.285736,
                  262.28564
                ]
              },
              "b": {
                "At": [
                  131.28574,
                  132.28552
                ]
              },
              "name": null,
              "ptype": "Curve",
              "data": null
            },
            {
              "x": 233.28574,
              "y": 324.2854,
              "a": {
                "At": [
                  351.28564,
                  334.2854
                ]
              },
              "b": {
                "At": [
                  115.285736,
                  314.2854
                ]
              },
              "name": null,
              "ptype": "Curve",
              "data": null
            },
            {
              "x": 342.28577,
              "y": 174.28549,
              "a": {
                "At": [
                  338.28577,
                  59.285492
                ]
              },
              "b": {
                "At": [
                  346.28574,
                  289.28528
                ]
              },
              "name": null,
              "ptype": "Curve",
              "data": null
            },
            {
              "x": 224.28574,
              "y": 54.285645,
              "a": {
                "At": [
                  124.285736,
                  43.285645
                ]
              },
              "b": {
                "At": [
                  324.2859,
                  65.285645
                ]
              },
              "name": null,
              "ptype": "Curve",
              "data": null
            }
          ],
          "operation": {
            "VariableWidthStroke": {
              "data": {
                "handles": [
                  {
                    "left_offset": 10.0,
                    "right_offset": 10.0,
                    "tangent_offset": 0.0,
                    "interpolation": "Linear"
                  },
                  {
                    "left_offset": 10.0,
                    "right_offset": 10.0,
                    "tangent_offset": 0.0,
                    "interpolation": "Linear"
                  },
                  {
                    "left_offset": 40.25149507653363,
                    "right_offset": 40.25149507653363,
                    "tangent_offset": -1.685716592159115,
                    "interpolation": "Linear"
                  },
                  {
                    "left_offset": 10.0,
                    "right_offset": 10.0,
                    "tangent_offset": 0.0,
                    "interpolation": "Linear"
                  },
                  {
                    "left_offset": 10.0,
                    "right_offset": 10.0,
                    "tangent_offset": 0.0,
                    "interpolation": "Linear"
                  }
                ],
                "join_type": "Round",
                "cap_start_type": "Round",
                "cap_end_type": "Round",
                "remove_internal": false,
                "remove_external": false
              }
            }
          }
        },
        {
          "inner": [
            {
              "x": 68.0,
              "y": 387.0,
              "a": "Colocated",
              "b": "Colocated",
              "name": null,
              "ptype": "Line",
              "data": null
            },
            {
              "x": 479.0,
              "y": 387.0,
              "a": "Colocated",
              "b": "Colocated",
              "name": null,
              "ptype": "Line",
              "data": null
            },
            {
              "x": 479.0,
              "y": 9.0,
              "a": "Colocated",
              "b": "Colocated",
              "name": null,
              "ptype": "Line",
              "data": null
            },
            {
              "x": 68.0,
              "y": 9.0,
              "a": "Colocated",
              "b": "Colocated",
              "name": null,
              "ptype": "Line",
              "data": null
            }
          ],
          "operation": null
        }
      ],
      "operation": null,
      "images": []
    }
  ],
  "history": [],
  "order": "Cubic",
  "anchors": [],
  "components": {
    "root": "M",
    "vec": []
  },
  "flattened": null,
  "component_rects": null,
  "guidelines": [],
  "width": 1085,
  "unicode": [
    "M"
  ],
  "name": "M",
  "note": null,
  "format": 2,
  "filename": "/tmp/vws_rev.glif"
}

Reproduction

1. Select the square by double clicking one of its points
   
2. Press Backspace

Crash

panicked at 'index out of bounds: the len is 4 but the index is 4', /home/fred/.cargo/git/checkouts/math.rlib-d2c76c88b18fa5ee/2547be6/src/variable_width_stroking.rs:138:28

Requested backtrace:
   0: MFEKglif::util::set_panic_hook::{{closure}}
             at src/util/mod.rs:61:26
   1: std::panicking::rust_panic_with_hook
             at /rustc/79e50bf77928f374921a6bcafee3fcff1915f062/library/std/src/panicking.rs:595:17
   2: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/79e50bf77928f374921a6bcafee3fcff1915f062/library/std/src/panicking.rs:497:13
   3: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/79e50bf77928f374921a6bcafee3fcff1915f062/library/std/src/sys_common/backtrace.rs:141:18
   4: rust_begin_unwind
             at /rustc/79e50bf77928f374921a6bcafee3fcff1915f062/library/std/src/panicking.rs:493:5
   5: core::panicking::panic_fmt
             at /rustc/79e50bf77928f374921a6bcafee3fcff1915f062/library/core/src/panicking.rs:92:14
   6: core::panicking::panic_bounds_check
             at /rustc/79e50bf77928f374921a6bcafee3fcff1915f062/library/core/src/panicking.rs:69:5
   7: <usize as core::slice::index::SliceIndex<[T]>>::index
             at /home/fred/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/index.rs:184:10
   8: core::slice::index::<impl core::ops::index::Index<I> for [T]>::index
             at /home/fred/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/index.rs:15:9
   9: <alloc::vec::Vec<T,A> as core::ops::index::Index<I>>::index
             at /home/fred/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/vec/mod.rs:2427:9
  10: MFEKmath::variable_width_stroking::variable_width_stroke
             at /home/fred/.cargo/git/checkouts/math.rlib-d2c76c88b18fa5ee/2547be6/src/variable_width_stroking.rs:138:28
  11: MFEKglif::contour_operations::variablewidthstroke::<impl MFEKglif::contour_operations::ContourOperation for glifparser::glif::mfek::VWSContour>::build
             at src/contour_operations/variablewidthstroke.rs:16:26
  12: MFEKglif::contour_operations::build
             at src/contour_operations/mod.rs:49:20
  13: MFEKglif::editor::operations::<impl MFEKglif::editor::Editor>::rebuild
             at src/editor/operations.rs:30:36
  14: MFEKglif::main
             at src/main.rs:308:9
  15: core::ops::function::FnOnce::call_once
             at /home/fred/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227:5
  16: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /home/fred/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:125:18
  17: std::rt::lang_start::{{closure}}
             at /home/fred/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:49:18
  18: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/79e50bf77928f374921a6bcafee3fcff1915f062/library/core/src/ops/function.rs:259:13
      std::panicking::try::do_call
             at /rustc/79e50bf77928f374921a6bcafee3fcff1915f062/library/std/src/panicking.rs:379:40
      std::panicking::try
             at /rustc/79e50bf77928f374921a6bcafee3fcff1915f062/library/std/src/panicking.rs:343:19
      std::panic::catch_unwind
             at /rustc/79e50bf77928f374921a6bcafee3fcff1915f062/library/std/src/panic.rs:431:14
      std::rt::lang_start_internal
             at /rustc/79e50bf77928f374921a6bcafee3fcff1915f062/library/std/src/rt.rs:34:21
  19: std::rt::lang_start
             at /home/fred/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:48:5
  20: main
  21: __libc_start_main
  22: _start


shell returned 101

In order to build Qglif on Ubuntu 20.04, I've noticed that I've had to install the following libraries (via apt-get):

• libxcb-shape0-dev
• libxcb-xfixes0-dev

I'm sure there are a few more that were needed that I already happened to have installed.

We should list the library requirements in README.md

Requires #5, #6.

Cf. http://www.corvelsoftware.co.uk/software/supertool/

The icons for add/remove/up/down are aligned oddly; the up/down look like unicode characters typeset with a system font, whereas the add/remove look like icons rendered from vector artwork.

I suggest using a comprehensive UI icon set packaged as a font, like the Material Design set on https://fonts.google.com/icons, so that you can get the best of both worlds

The italic grid gets closer together the higher the slope value.

Suggested by Dave Crossland on Twitter. I think this is a good idea and will look into this soon after finishing the image tool.

Would appreciate @eliheuer telling me his favorite style of quadratic pen so I can just implement that. The current pen is cubic Bézier only, attempting to use it in a quadratic glyph will cause an assertion error, intentionally.

This says it all:

https://github.com/rust-windowing/winit/blob/386ead15a3e3fef5c0c02bd7491d3cc9a7a6e0aa/src/platform_impl/linux/x11/events.rs#L178

//ffi::XK_numbersign => VirtualKeyCode::Numbersign

🤦‍♂️_{🤦‍♂️🤦‍♂️} 😱❗❗❗

Issue discovered by @eliheuer in his Twitch stream. Confirmed and cause found just now by @iwsfutcmd.

I don't trust any software with code like this commented out period. They have no idea what they're doing in my humble opinion. The fact that Subtract and Minus were only recently unified is shocking as well.

So, this is an urgent issue. I had hoped not to need to rewrite main.rs again, but I don't mind given the severity of their keyboard handling.

SDL2 supports Unicode input, so console will still work without much worry about hooking OS APIs for IME's etc.

When pressing the arrow keys the viewport is moved to origin + the movement of the arrow keys.

Inspired by https://typedrawers.com/discussion/4052/using-b-splines-to-draw-italics#latest I thought I'd propose that :)

Hey.

I am not a coder, so I'm likely doing something wrong here, but I can't compile due to this error

error[E0308]: mismatched types

it tells me in my .cargo/registry/src/github.com-1ecc6299db9ec823/skulpin-renderer-0.4.1/src/skia_support.rs file it's expecting Option<unsafe extern "system" fn() -> c_void> and only finding Option<unsafe extern "system" fn()>

seems really silly to me because when I look at the skia_support.rs file it reads "Option<unsafe extern "system" fn() -> c_void" which is what it's claiming to want it to say so IDK what it's on about here.

I'm running rustc 1.52.0-nightly

let me know if there's any other info you'd need from me.

lovely project, truly the font editor we all need

I'm not the best at this type of thing so I'd really love some input on what the colors should look like.

Currently the way we store images is problematic in a few ways. We're holding an affine matrix that represents the image transform, which works, but decomposing this matrix back into scale, rotation, shear, etc. is somewhat complicated and introduces rounding errors.

I'd like to change it so if we load an existing image from a UFO it maintains it's matrix, but when a user adds a new image through MFEK we keep scale, shear, rotation, etc. as separate variables the user can modify and then composes the matrix each frame. This allows users to easily specify very specific angles they want the image to appear at, and does not introduce rounding errors to the values the users see on the user interfaces (ex 45 -> 45.00006 after decomposition). On export we'd compose an affine matrix out of these values and store it in the standard manner for UFO images.

On the topic of a user importing images the image would not be able to be modified in this way until the user clicks a button to clear the existing matrix, and then our method would take over from there.

While writing #103 (comment) I was reminded that most editors with good plugins get a "replace save() with git.commit()" plugin, and it's possibly so useful to be a good candidate for an out of the box feature.

Lmk if you want links to prior art, but it's a fairly simple concept.

Still, it can go deeper, such as adding auto save with auto commit message, dialog to capture commit messages, advanced UI for file and even line selection, stash, branching and tagging, push/pull.

Possibly this is related to the inotify hot reload of UFO stuff, since checking out another commit will trigger that, etc

We're considering abandoning the idea of using the UFO file format as our internal format, and simply using JSON that's converted back upon export. The problem being when external tools are used they might modify layer 0 and make MFEK data attached to that layer. There are two ways to solve this problem:

1. Check our internal layer 0 against the UFO layer 0 and prompt the user to clear the associated MFEK data.
2. Abandon the idea of trying to maintain a UFO compatible layer 0 and save only in JSON format until export.

@eliheuer suggested I make some issues so people know my plans.

Pressing : should open a console, similar to Yakuake and Vim. You type a command, like :selectall or :set CLEAR_COLOR 0xff_000000, pressing enter executes command.

Qglif will not have menus, it will only have hotkeys and a console.

E.g. /home/fred/.local/share/Qglif/theme.toml.

ascender and descender are inserted into MFEKGlif's guidelines field during loading by MFEKmetadata. They aren't actual user-added guidelines and shouldn't actually appear in files if they aren't parented.

This bug is minor but causes two strange effects…

It causes more and more guidelines of these names to be written to the file upon every save. This causes the ascender/descender line to both appear darker, and also probably results in illegal .glif data (oops)

Time has come for this; I've inadvertently broken the build on other platforms a few time already.

Trouble is, I've never written a CI recipe from scratch before. Quite embarrassing, yes.

Maybe @eliheuer @jtanx @iwsfutcmd have ideas. (Why didn't you accept invitation to join organization btw Eli? I wanted to assign you to #7.)

Just a heads up, building this from the release source fails with the following error:

error: git describe failed with status 128: fatal: not a git repository (or any of the parent directories): .git
  --> src/util/argparser.rs:21:40
   |
21 |         .version(&*format!("{}-alpha", git_version!()))
   |                                        ^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `proc_macro_call` (in Nightly builds, run with -Z macro-backtrace for more info)

Probably best to just install it from a git clone anyway but I wanted to share just so you know.

Relates to #23 and might be doable in same commit

Context: I’m on macOS 10.15.5 and I wanted to install this to try it out. I had a few hurdles in doing so, and I’ve figured them out but will leave this issue (and close it) in case it helps others who have the same issues.

I was curious to check this out, but after following the directions to install vulkanSDK & rustup, the build was stopped at an error:

   Compiling glifparser v0.0.0 (https://github.com/mfeq/glifparser#e3c77586)
error[E0554]: `#![feature]` may not be used on the stable release channel
 --> /Users/stephennixon/.cargo/git/checkouts/glifparser-a0b09305bd94eda1/e3c7758/src/lib.rs:1:1
  |
1 | #![feature(assoc_char_funcs, let_chains)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   Compiling aho-corasick v0.7.13
error: aborting due to previous error

For more information about this error, try `rustc --explain E0554`.
error: could not compile `glifparser`.

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed

So, I ran rustc --explain E0554 as suggested, and realized that I hadn’t quite followed all the instructions – I hadn’t configured the rust installation to use the nightly toolchain.

So, I ran the build again, and ... I got another error:

   Compiling skulpin v0.10.0
   Compiling Qglif v0.1.0 (/Users/stephennixon/code/Qglif)
    Finished dev [unoptimized + debuginfo] target(s) in 52.55s
     Running `target/debug/Qglif Q_.glif`
[2020-09-13T01:33:18Z DEBUG Qglif::io] Loaded "Q" (U+0051) from Q_.glif
[2020-09-13T01:33:18Z DEBUG Qglif::imgui::support] Building ImGui font atlas
[2020-09-13T01:33:18Z INFO  skulpin_renderer::instance] Finding vulkan entry point
Error during renderer construction: CreateInstanceError(LoadingError(LoadingError(DlOpen { desc: "dlopen(libvulkan.dylib, 2): image not found" })))

I found that this is because I misunderstood the vulkanSDK Getting Started guide. I tried to do the main method of moving the DMG files into a folder within my home directory. However, I had to also do their "Alternate method" of running the ./install_vulkan.py script.

With this, the build worked!

Qool! (Dumb joke, sorry.) Looking forward to playing with this a bit. Thanks for making this pretty straightforward for newcomers to build!

right now glif won't run unless the .glif file is part of a UFO, the suggested command
RUST_LOG=debug RUST_BACKTRACE=1 cargo run -- examples/Q_.glif
doesn't run right now? (small)

also it needs vulkan drivers, which is mentioned for mac but not included in linux instructions

small in either case, not hard to figure out

See also iced-rs/iced#520.

(filing here and you can transfer to the ufo repo when you make it public)

https://twitter.com/fr_brennan/status/1397723808191156230?s=19 shows a typical glyph view grid:

One of the early mocks Eli did for runebender showed proportionally spaced cells,

But the current runebender uses a monospace grid, with eliding longer glyph names and overflow of larger glyphs, like the honorific here:

• So I think a "scale factor" (like Glyphsapp and Robofont and fontlab have, with a slider on the bottom toolbar, and fontforge has as a set of size options in the view pulldown, as I recall), can be complimented by a
• monospace default with a proportional toggle, and
• theming for the background, cell border, cell background, foreground, label bg/fg color, label eliding technique (2+ lines, middle ellipsis, end ellipsis, etc)

Requires also adding Spiro support to mfeq/glifparser

Prerequisite: #5.

I've been unable to reliably recreate this bug, but it's a pretty high priority. I'm not sure how or why it even happens. If anyone @ctrlcctrlv runs into this bug again a stack trace or repeatable instructions would be worth the world to me.

Cf. http://www.corvelsoftware.co.uk/software/supertool/

Easy with 642e30d.

Having the corners, show_sel_box and the new vws_previews and vws_contours in the global state seems hacky, I think I need to come up with some way to have tool-level state, which is set at the time of tool switch.

So maybe each .rs file in events can define a thread-local state variable, containing a different type, and TOOL_DATA can become a reference to the current tool's data, or something.

Maybe tool data state variables should be a HashMap. Gotta think more about this.

Requires #13.

Cf. http://www.corvelsoftware.co.uk/software/supertool/

I would like to setup Arch Linux packaging for this project, but right away I'm faced with some guideline problems. Naming the package is difficult. I would like to propose some upstream reorganization here to make downstream usage more consistent.

The biggest issue is that capital letters in binary names are strongly discouraged. Guidelines on this vary by distro. I know there are a few distros that 100% enforce this and there are some that don't care at all. Arch Linux is somewhere in the middle: it strongly dislikes them but has allowed a few exceptions. For example historical reasons have given X a pass. There are also a handful of others. Many more projects are relegated to keeping their upstream capitalized versions to the side and linking a lowercased version from /bin. For example Virtual Box, whose upstream binary name comes out as VBoxManage is symlinked from vboxmanage.

For Arch Linux packaging, upper casing the name of the package is completely disallowed, I can't even submit a package except in lower case. The binary inside doesn't have to match the package name, but I would probably need to at the very least symlink a lower cased version or more likely just lower case it after build.

I would like to recommend that this project adopt a naming scheme that will be more likely to be implemented with no changes downstream: Lets rename the binary generated here from MEFKglif → mefk-glif. That will still leave room for other binaries in the mefk-... namespace. It will also make it easier to search for packages (dashes as separators help by virtue of being valid word boundary so "whole word" searches for glif or mefk will come up positive. The dash notation for subcommands is also pretty widely recognized these days (cf. git-...).

I do realize there is a bit of a hyphen vs. underscore fiasco in progress in the world of Rust crates. Avoiding the whole thing would be the biggest reason to not add the dash, but honestly I think it will be better off

If this is agreeable I'd be happy to put it together as a PR.

Alternatively, simply glif might actually work as a package & binary name. I initially assumed that would be a hard name to claim, but I don't actually see anything in that namespace at all in any major distro.

A better panic hook that could display the error in a dialog would be good for non-technical users.

We could perhaps package something like a cross-platform zenity, if that exists. Just something that can use native API's to create a quick dialog under any OS. I could easily code one for Windows and Linux, but no clue about OS X. I feel like something must exist. Will look into.

Qmetadata is ready.

I just tested commit 9b1c006 on Arch with Nightly and it worked without issues.

However, on macOS 10.15 I get a series of errors. It would be nice if this worked well on macOS and I'm happy to be a macOS tester for this editor.

The first error I get reads:

error[E0599]: no function or associated item named `from_u32` found for type `char` in the current scope
   --> src/glifparser.rs:203:23
    |
203 |                 char::from_u32(u32::from_str_radix(unicodehex, 16).expect("<unicode> hex not int"))
    |                       ^^^^^^^^ function or associated item not found in `char`
    |
help: you are looking for the module in `std`, not the primitive type
    |
203 |                 std::char::from_u32(u32::from_str_radix(unicodehex, 16).expect("<unicode> hex not int"))
    |                 ^^^^^^^^^^^^^^^^^^^

I fixed this but got a few more errors and couldn't get it to build, I might try a PR to get it working, but thought I would post the issue first so you know I'm thinking about it.

Thanks!

The toolbar's selection is offset when mousing over or selecting a tool.

Toolbar:

Main view port:

The main view port does not seem to suffer from this problem, and behaves correctly.

A few interesting cross-platform crates exist for this, so I think it's something real simple to do. Let's see though...

This will stop us from needing to just error out if no filename is provided, helping Windows users who may want to just double click Qglif.exe and be on their merry way.