Does the average user need to edit name tables or set bit flags? Name tables are likely useful so that they can create distinct families with whatever they generate using the application. I think that at least min naming functionality belongs in a default. We can likely move deeper name record editing and style name mapping bit flag sets/clears, any other necessary binary editing tools into an advanced panel to reduce clutter for those who don't need this functionality.

The progress is indicated in the status bar but it might be helpful to launch a more obvious dialog window with an animated indefinite progress indicator bar during the slicing execution.

I don't want to install app and make some traces at OS registry and system user folders (C:\Users...). I want zip- or 7z-file to unpack it everywhere and launch.

Is it possible to create it and publish there, please?

This is an excellent suggestion from Stephen Nixon. It might be helpful to pull the fvar and/or STAT table defined named instance data in variable fonts and provide a fast/easy way to expose those instances to users for instancing. I really like this idea.

These are likely to be the most commonly needed instances in production fonts. This tool has potential use cases during development before these named instances are defined (e.g. designer creates temp design axes and user slices the designspace to review in static font format as defaults are being defined) so we will need to fall back gracefully if there are no named instances available.

Set Win executable checksums with PyInstaller to address some false positives detected on VirusTotal scans

Original report: pyinstaller/pyinstaller#5579

Update released in PyInstaller 4.3

Dependency PR with PyInstaller update #24

This app currently supports the following sub-space output fonts from input variable fonts:

• static instance = all axis values are pinned to a discrete location value
• partial instance / variable sub-design space = combination of static axes that include a discrete axis location value and variable axes with the full axis range that was available in the input variable font

I've received requests to support variable font outputs that include variable axes with a reduced axis range compared with the input font. This is not currently supported in the fonttools library that we rely on for the slicing operation in this project. (this is partially supported at level 3, see #31 (comment), documentation updated in fonttools/fonttools#2280)

fonttools related issues:

• fonttools/fonttools#727
• fonttools/fonttools#2157
• fonttools/fonttools#1537 (comment)

https://github.com/fonttools/fonttools/blob/cf8deef42045fb0a4141e43025a92ae2a203813d/Lib/fontTools/varLib/instancer/__init__.py#L1151

TODO:

• define idiom for the range restriction request
• add L3 level range request validation (user must include the axis default in the requested range)
• implement the slicing operation with fonttools.varLib.instancer.instantiateVariableFont (50009fc)
• revise format of the min, max, and default axis values so that they match syntax used to define range restriction with changes here (ec49583)
• add tests
• update docs (source-foundry/Slice-docs#1)

Perhaps use a toast / dialog window message? The goal is to make it easy to locate the file after the file write.

Probably:

• deb
• rpm
• pacman
• tar.gz

Hi
name table entries are too much in some cases and cause confusion for end user in desktop applications, i suggest add another way(enabled with checkbox in GUI) to search and replace string(i mean for example via internal font to ttx conversion, search and replace in ttx and ttx back to the font)

A list of other possible records that could be edited:

• post.isFixedPitch
• OS/2.panose.bProportion
• OS/2.xAvgCharWidth

Related: "default" and "advanced" task support #14

I get the following error message: "No module named brotli".

Given the error message, I'm wondering if the fix would be to import fonttools with the woff extra.

Santiago Orozco attempted to install the macOS application bundle that I compiled on macOS 10.15.7 and the application does not work on macOS 10.14.x. Per documentation, it sounds like there are platform-specific forward compatibility but not backward compatibility guarantees with the PyInstaller approach so we'll need to find a way to build releases on earlier macOS versions. Possibly through GH Actions. Unclear how code signing works with the remote approach. I'll look into it.

The drag and drop font path string functionality works fine on macOS and Linux. On Windows, there is a leading \ character that makes this an invalid file path. The approach to the drag/drop event needs to be updated along the lines of

https://bugreports.qt.io/browse/QTBUG-46417

The font load works via the Open menu item and the Open button dialog.

Automate the addition of the file extension during the file write process if the user does not include an extension in the Save dialog.

https://github.com/Homebrew/homebrew-cask/blob/master/CONTRIBUTING.md

Sub-spacing a design axis to a range that does not include the default value requires compile-time editing of the default axis location. This is not currently supported in the fonttools library used to compile fonts in this project.

We intend to support this functionality when it is available in the library.

Related issue on the fonttools tracker: fonttools/fonttools#2157

• First I tried with Slice 5.0, installed via OSX dmg file, using Recursive VF 1.078
• Setting a single value for wght works to generate a static TTF, eg: 400
• I would expect that entering a range of values would work to slice a sub-space VF, eg: (300.0, 400.0) [300.0]
  but this results in a crash in version 5.0. In version 4.0 I get an error (see screenshot below) which says

Could not convert string to float: '(300.0, 400.0) [300.0]'

• I tried with 2 var fonts of my own with the same crashing result and DJR observed the same issue on his machine with v5.0 installed via homebrew, so I know the issue is not limited my set up or to the Recursive font

Thanks so much for your consideration, and for your work on this app, it looks very promising!

Hi
is there a way to run Slice through command line? i need to work with Slice as a part of build process.

We do not currently remove overlaps in builds with all axes defined at a static instance locations. We use the default approach defined in fontTools.varLib.instancer.instantiateVariableFont. This keeps overlaps and sets the OVERLAP_SIMPLE & OVERLAP_COMPOUND bits on glyphs in the glyf table. This can lead to platform-specific issues with contour overlap rasterization where pixel dropout is seen in the area of the overlap.

It would be helpful to include the option to remove overlaps when you build static instances. We will keep the current approach as the default because the removal of overlaps can lead to issues in fonts with instruction sets as the points/order change when overlaps are removed.

Perhaps as a selectable menu option, in an options panel, or in a checkbox on the UI? Will look into this.

e.g., full RIBBI family

Users run into the "from an unidentified developer" message on macOS. This can be addressed by going through the formal code signing process. For now, we can add docs to show users how to use an application when this message pops up.

The bottom of the window with the "Slice" button are not visible thus not clickable (going beyond 1600px height)

During testing of the v0.6.0 release that added woff and woff2 format support, I came across an issue with the output file extensions in Win 10. When I enter an output file path of test.woff or test.woff2 with the proper input file format, the file write is on the path test.woff.ttf or test.woff2.ttf. This seems to be something that Win OS is doing on its end from what I can tell. Requires further investigation.

Related #34

I downloaded the dmg for macOS just to find out that the App won't start on 10.13. I could not find this mentioned anywhere in the documentation pages. Would be nice to get an early warning ;)

@chrissimpkins Answer: Current repository releases require macOS 10.14 and above. macOS install docs updated. Users on macOS < 10.14 can build the app bundle with the instructions in #40 (comment). Looking into a way to support earlier macOS versions in our releases.

I'm trying to create a single cut of the excellent Recursive with its mono axis set to 0.51. At this value a bunch of characters are substituted for their monospaced slab-serif alternates (check out r which is substituted for r.mono). Unfortunately when I set up slice with a mono value of 0.51 it does not perform this substitution, and because the typeface is output as a single axis I cannot select this substitution in most (any?) software as it's a contextual alternate and won't appear in a stylistic set or ligatures option.

It would be helpful to have the option to bake those types of character substitutions specifically into the sliced font file? Somewhat niche use case, I know!

Otherwise this tool works quite well and is very helpful! Thank you for making it :)

Related to #18

I was on Repology today and the slice scene has an identity crisis. When I packaged for Arch Linux there were no name conflicts on slice and it was a shoe-in to just use that name. I see the situation is different on Debian/Ubuntu where a long abandoned text templating project using set theory has taken up the Debian package name. The project is only available on archive.org and the last release was in 2002, but that doesn't mean the Debian namespace is going to clear out any time soon.

I'm inclined to suggest keeping the project and binary name as slice for now. I plan to keep that package name in Arch unless something changes. But no matter how much we want it that still leaves the Debian package namespace with a conflict. Any attempt to package this for Ubuntu is going to run into this issue.

I suggest this upstream project come up with an suggested name for packages if/when conflicts arise. This way we don't end up with a bunch of downstream package names that aren't coordinated.

I've suggested to Repology that they rename the legacy project asci-slice or wml-slice, but that only solves the issue for their display system. Any Debian family packages will still need some alternative name to disambiguate themselves.

It would be helpful to get a command line / python script equivalent to the output of the app, so that the results can be reproduced without manually using the app.

Related: #40

Users on macOS 10.13 and below cannot use the project macOS application package releases. It is necessary to either run from source (e.g., with a PyPI installation or cloned repository) or for the user to compile the package themselves (see https://slice-gui.netlify.app/docs/developer/#compile-app-distributions-by-platform). This is due to the backwards compatibility guarantee (or lack thereof) with the PyInstaller tool that is used to prepare the platform-specific distributions.

I think that I can address this by setting up a new, earlier macOS VM for the package build. Will require testing to confirm that the same build works on more recent versions of macOS.

Related #34

The bit flags weren't set for me, but I think they can be inferred:

Recommended by @arrowtype.

How difficult would it be to add a VF previewer with rasterization that implements the in app user axis value settings? I'm not aware of VF format support in Qt text views. Perhaps we could consider something like Qt WebEngine draws with dynamic HTML writes? Not sure. Great idea, cool feature. Needs further investigation.

"Partial instantiation" = final file includes variable design axis support for at least one axis, other axes are instanced (not currently supported in Slice)
"Static instantiation" = final file has no variable axes, all axes are instanced (current approach in Slice)

Perhaps it is just a character restriction (square brackets illegal?) but I couldn’t paste an output filename into the Save dialog in the GUI. I could type the exact same filename, though.

It was of the format: “FontName[AXIS1,AXIS2,opsz,wght].ttf”

The harfbuzz subsetter is a compiled C++ lib that supports variable to static font instantiation. This appears to be exposed through the uharfbuzz Python bindings and it should be significantly faster.

https://github.com/harfbuzz/uharfbuzz/blob/da2e6d5a2c4607276378c84f0ba1fd3bf362beed/src/uharfbuzz/_harfbuzz.pyx#L387

so, I think that we could do something along the lines of the following:

import uharfbuzz

with open(fontpath, "rb") as fontbin:
        hb_face = uharfbuzz.Face(fontbin.read())

hb_font = uharfbuzz.Font(hb_face)

variation_axis_defs = {
    "opsz": "10",
    "wght": "700",
    "GRAD": "-25",
}

hb_font.set_variations(variation_axis_defs)

# TODO
# how do you write binary back to disk? 

It isn't clear to me based on a quick read through of the hb source what level of feature support it has relative to the pure Python varLib.mutator and varLib.instancer libs.

Questions

• What are the differences (if any) relative to fontTools.varLib.mutator? fonttools/fonttools#2248 (reply in thread)

It might be helpful to include a pre-populated default file path in the Save dialog prompt that opens when the Slice button is clicked.

on v0.7.1, when slicing and renaming a font, only the windows names where changed and not the Mac Names, see the screenshot below. "Jaune Midi Var" was the target name.


Beside that, worked like a charm! <3

Length will be an issue in the current tabular format. Perhaps we begin by supporting this as tooltips when you mouse over the axis tag?