chrissimpkins ( Chris Simpkins )

gftools unable to handle folder names with spaces?

I don’t know if related, but I am also getting a permission error. This is running the latest merge of the build script from @vv-monsalve on Mac OS.

= Post procesing TTF
Traceback (most recent call last):
  File "../venv/bin/gftools", line 99, in <module>
    p = subprocess.Popen(args, stdout=sys.stdout,
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/subprocess.py", line 1702, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
PermissionError: [Errno 13] Permission denied: '../venv/bin/gftools-fix-hinting.py'

Ugh... @vv-monsalve @tiroj I suggest trying a change of all of the python [path]/gftools [sub-command] calls to python [path]/[gftools script that is called by gftools executable]. These names are formed by replacing the space between gftools and [SUB-COMMAND] with a hyphen and adding a .py. e.g.,

python ../venv/bin/gftools fix-hinting [FONT]

becomes

python ../venv/bin/gftools-fix-hinting.py [FONT]

You'll find the full list of script names in https://github.com/googlefonts/gftools/tree/master/bin

tiroj

comment created time in 4 days

issue commentgooglefonts/gftools

gftools unable to handle folder names with spaces?

Seems related: pypa/virtualenv#53

😆 From that thread. Life in 2020...

2020-10-16_13-39-17

tiroj

comment created time in 4 days

Pull request review commentgooglefonts/fontbakery

Ignore zero advance-width glyphs at com.google.fonts/check/monospace

 def glyph_metrics_stats(ttFont):     ascii_glyph_names = [ttFont.getBestCmap()[c] for c in range(32, 128)                          if c in ttFont.getBestCmap()]     ascii_widths = [adv for name, (adv, lsb) in glyph_metrics.items()-                    if name in ascii_glyph_names]+                    if name in ascii_glyph_names and adv != 0]

I'm not sure that this influences the issue report if I understand the change correctly Felipe. This looks like it is a "is it a monospaced font" side definition change. The fonts that I tested were designed as monospaced fonts. We successfully passed that test and the result was correct. The issue that I found was that when it is a monospaced font, there are glyphs outside of the ASCII set that are detected as inappropriately defined in a monospaced font b/c they have zero advance widths. These were in the combining mark glyph set which are compiled with zero advance widths. Please let me know if I can provide any additional information

felipesanches

comment created time in 5 days

PullRequestReviewEvent

pull request commentchrissimpkins/cinder

Display permalinks on hover

All set to go here after https://github.com/chrissimpkins/cinder/pull/95/commits/92bedf98e1e84a4f51b70c5b45ffb739742bf630 @anlau?

anlau

comment created time in 5 days

issue commentgooglefonts/gftools

gftools unable to handle folder names with spaces?

I can totally reproduce this. Seems to me venv related.

Which venv did you use? A locally generated one? I changed the build following Chris workaround. Under my local venv both, the previous and the current build worked for me locally,

Users should always be creating their venv environment locally. You don't want to commit your venv directory to your git history.

tiroj

comment created time in 5 days

issue commentgooglefonts/gftools

gftools unable to handle folder names with spaces?

Thanks, Chris, for the detailed answer.

in a clone of your repo that includes a venv directory path with spaces

Do you mean a venv included in the repository? I'm curious since there was one, but I deleted it as it is not the suggested practise to include it in the repository.

You can add venv to your .gitignore. It should not be pushed to the remote. But it is ok to include it in repo locally IMO. Not aware of guidance about the practice out there.

It definitely looks like the venv installed executables do not like spaces in directory paths

So, for clarification, the main source of conflict in this case would be the spaces in directory paths. It wouldn't matter if a new venv is created for the directory it would still have those, that's why in this case including the path to ../venv would be the best solution. Is that it?

It appears to be the spaces in the absolute directory path that John was using above the level of the repository directory. Any space in that path. I tested it by adding a space in the repository directory name and, in a separate test, the venv directory name, it caused issues in both cases.

A workaround for absolute paths with spaces is to use explicit relative file paths to the venv installed executable sources.

Thanks, I'll try that and let you know the outcome :)

G/L!

tiroj

comment created time in 5 days

issue commentgooglefonts/gftools

gftools unable to handle folder names with spaces?

I reproduced this with macOS 10.15.5 / cPython 3.8.6 in a clone of your repo that includes a venv directory path with spaces. It definitely looks like the venv installed executables do not like spaces in directory paths. You might check the fontmake that you are using within the venv too. In my activated venv it looks like this is the system installed version of fontmake and not the venv installed version. That could be an important issue if you intend to fix the compiler version in your build workflow.

A workaround for absolute paths with spaces is to use explicit relative file paths to the venv installed executable sources. This works for me and should support anyone who builds from a virtual environment directory that is named venv at the root of your repository:

`src/build.sh`

#!/bin/sh
set -e

mkdir -p ../fonts/otf ../fonts/ttf

echo = "Generating TTFs"
../venv/bin/fontmake -u ./UFO/Castoro-Regular.ufo -o ttf --output-dir ../fonts/ttf -a
../venv/bin/fontmake -u ./UFO/Castoro-Italic.ufo -o ttf --output-dir ../fonts/ttf -a
# fontmake -m ./UFO/Castoro_Roman.designspace -o ttf --output-dir ../fonts/ttf -a
# fontmake -m ./UFO/Castoro_Italic.designspace -o ttf --output-dir ../fonts/ttf -a

echo = "Post procesing TTF"
ttfs=$(ls ../fonts/ttf/*.ttf)
for ttf in $ttfs
do
    python ../venv/bin/gftools-fix-hinting.py $ttf
    mv "$ttf.fix" $ttf
    python ../venv/bin/gftools-fix-dsig.py -f $ttf;
    python3 castoro_stat_table.py $ttfs
done

echo = "Generating OTFs"
../venv/bin/fontmake -u ./UFO/Castoro-Regular.ufo -o otf --output-dir ../fonts/otf
../venv/bin/fontmake -u ./UFO/Castoro-Italic.ufo -o otf --output-dir ../fonts/otf
# fontmake -m ./UFO/Castoro_Roman.designspace -o otf --output-dir ../fonts/otf
# fontmake -m ./UFO/Castoro_Italic.designspace -o otf --output-dir ../fonts/otf

echo "Post processing static OTFs"
otf=$(ls ../fonts/otf/*.otf)
for otf in $otf
do
	python ../venv/bin/gftools-fix-dsig.py -f $otf;
    psautohint $otf;
done

echo "Done!"

tiroj

comment created time in 6 days

issue commentfigma/community

Variable Font Support

+1

rememberlenny

comment created time in 6 days

pull request commentchrissimpkins/hl

Bump regex from 1.4.0 to 1.4.1

@dependabot merge

dependabot-preview[bot]

comment created time in 7 days

pull request commentchrissimpkins/cinder

Display permalinks on hover

Sounds good to me. Let's go with that approach.

anlau

comment created time in 7 days

pull request commentsource-foundry/fdiff

Bump yarl from 1.6.0 to 1.6.2

@dependabot merge

dependabot[bot]