kohler / lcdf-typetools Goto Github PK

Hi,

I have a font which has a single glyph mapped into more than one code point (attaching screenshot from fontbook). when dumping the glyphs from the font via otfinfo -u , the second mapping does not appear. as the font is commercial, I unfortunately cannot provide the sample. see screenshot.

Gils-MacBook-Pro:OpenType gilbahat$ otfinfo -u Whitney-Medium-ProGkCy.otf | grep 162
uni0162 424 Tcommaaccent
uni0423 162 uni0423
Gils-MacBook-Pro:OpenType gilbahat$ otfinfo -u Whitney-Medium-ProGkCy.otf | grep 21A
Gils-MacBook-Pro:OpenType gilbahat$

the expected behaviour is to see uni021A 424 Tcommaaccent as well in the output.

Gil

When displaying font information with otfinfo (--info), it would be nice to include fontRevision field from table head (see Microsoft Typography: head – Font Header Table). Sometimes font manufacturers don't update the version string in table name, but they do update the fontRevision.

See also [Fontconfig] where does fc-query get its fontversion from?

otfinfo reports Cyrillic in TeX Gyre Pagella:

$ otfinfo --scripts texgyrepagella-regular.otf
DFLT		Default
cyrl		Cyrillic
latn		Latin
latn.AZE	Latin/Azeri
latn.CRT	Latin/Crimean Tatar
latn.MOL	Latin/Moldavian
latn.NLD	Latin/Dutch
latn.PLK	Latin/Polish
latn.ROM	Latin/Romanian
latn.TRK	Latin/Turkish

In fact there is no Cyrillic Unicode block there:

$ otfinfo --unicode texgyrepagella-regular.otf | grep -P 'uni04[0-9A-F][0-9A-F]'

texgyrepagella-regular.zip

I notice that HEAD of git contains several changes that look like important bugfixes, which has lingered there for almost a year now.

I wonder if those are safe to cherry-pick? Concretely my concern is Debian (for which I maintain distribution of this project) that will soon make a stable distribution release.

Would it perhaps be time for a new formal release of lcdf-typetools?

I tried to build the current repository on Lubuntu 14.04.2.

I am not able to interprete the message. I put some version information in the output.

checking for fabs... yes
./configure: line 5272: syntax error near unexpected token `FIXLIBC,'
./configure: line 5272: `AM_CONDITIONAL(FIXLIBC, test x$need_fixlibc = x1)'

user@MONSTER:~/share/work/lcdf-typetools$ make --version
GNU Make 3.81

user@MONSTER:~/share/work/lcdf-typetools$ autoconf --version
autoconf (GNU Autoconf) 2.69

The scripts in showings subdirectory create PDFs displaying some OpenType features.

It would be quite a bit of an improvement for easier visual comparisons of suble differences, if each of the text "patches" would display on a different page, instead of four patchse per page.

One way to achieve this would be by using a custom page size such as 842pt x 211pt as could be provided by the geometry package of LaTeX:

\usepackage{geometry}
    \geometry{paperwidth=842pt, paperheight=211pt, margin=48pt}

Hi

otfinfo -f

dtls <unknown feature>

Dotless Forms dtls

Cheers, Ian

The LaTeX package SimpleIcons, https://www.ctan.org/pkg/simpleicons, used to use otftotfm to convert SimpleIcons.otf into SimpleIcons.pfb.

When a document used that SimpleIcons.pfb, the glyphs were shown in several pdf-viewers, but NOT in Adobe Acrobat Reader (on Windows), where there was just white space. (Well, the icon was there, but at about 0.00001 % of intended size.)

When converting SimpleIcons.otf into SimpleIcons.pfb by Fontforge, then also Adobe Acrobat Reader (on Windows) correctly presents the glyphs/icons.

Thus something with the font conversion via otftotfm is amiss.

The SimpleIcons package now uses Fontforge, but otftotfm should be repaired.

The issue has already been discussed at

https://tex.stackexchange.com/questions/689446/compatibility-issue-between-the-simpleicons-package-otftotfm-and-adobe-acrobat

and

ineshbose/simple-icons-latex#11

which give additional insights but no fix for otftotfm.

When compiling lcdf-typetools with msys2 on Windows, I had to change

g++  -g -O2   -o cfftot1.exe cfftot1.o maket1font.o ../libefont/libefont.a ../liblcdf/liblcdf.a
g++  -g -O2   -o otfinfo.exe otfinfo.o ../libefont/libefont.a ../liblcdf/liblcdf.a
g++  -g -O2   -o otftotfm.exe automatic.o dvipsencoding.o glyphfilter.o metrics.o otftotfm.o secondary.o uniprop.o util.o  ../libefont/libefont.a ../liblcdf/liblcdf.a
g++  -g -O2   -o ttftotype42.exe ttftotype42.o ../libefont/libefont.a ../liblcdf/liblcdf.a

into

g++  -g -O2   -o cfftot1.exe cfftot1.o maket1font.o ../libefont/libefont.a ../liblcdf/liblcdf.a -lws2_32
g++  -g -O2   -o otfinfo.exe otfinfo.o ../libefont/libefont.a ../liblcdf/liblcdf.a -lws2_32
g++  -g -O2   -o otftotfm.exe automatic.o dvipsencoding.o glyphfilter.o metrics.o otftotfm.o secondary.o uniprop.o util.o  ../libefont/libefont.a ../liblcdf/liblcdf.a -lws2_32
g++  -g -O2   -o ttftotype42.exe ttftotype42.o ../libefont/libefont.a ../liblcdf/liblcdf.a -lws2_32

to make the build succeed. I didn't yet try to figure out where to change this (I assume somewhere in configure.ac).

Otherwise I get the following error(s):

g++  -g -O2   -o cfftot1.exe cfftot1.o maket1font.o ../libefont/libefont.a ../liblcdf/liblcdf.a
../libefont/libefont.a(otf.o):C:\Programs\MSYS\msys64\home\me\lcdf-typetools\libefont/./../include/efont/otfdata.hh:122: undefined reference to `__imp_ntohs'

Hi

otfinfo -u appears to stop at U+FFFF.

Is it possible at add support for higher planes? eg Ancient Symbols : U+10190 .. U+101CF ?

Also, otfinfo -s
latn.ANG Latin/<unknown language>

ANG is English, Old (ca.450-1100)

Thanks, Ian

This line references options that are not available, hence they should be replaced by --x-height=x and --x-height=font as explained in https://tex.stackexchange.com/questions/629932/is-there-an-option-use-x-height-for-otftotfm/629936#629936

The otftotfm option --math-spacing=255 is causing math accents to kern nicely for all characters except f, j, p and y, who coincidentally are the characters who have the most glyph space added. Considering that they are all skewed too much to the right (f is a special case as it is super wide), my wild guess is that something about the process of heuristically generating the accents is not taking into account the added space.

What adds to my suspicion is the fact that the dotless-j glyph has the accent even outside the glyph itself.

This may not be a big problem for fonts with a small italic angle, but in the case mostly of the f and j here the results are strange.

Example font generation command and MWE (I think autoinst mostly runs otftotfm but please correct me):

autoinst -lining -oldstyle -proportional -tabular -smallcaps -swash -titling -superiors -inferiors=subs -ornaments -fractions -defaultoldstyle -defaultproportional -noupdmap -nofigurekern -encoding="OML" -extra="--math-spacing=255 --letterspacing=75 --no-updmap" GaramondPremrPro.otf GaramondPremrPro-It.otf

autoinst -lining -oldstyle -proportional -tabular -smallcaps -swash -titling -superiors -inferiors=subs -ornaments -fractions -defaultoldstyle -defaultproportional -noupdmap -nofigurekern -encoding="OT1" -extra="--no-updmap" GaramondPremrPro.otf GaramondPremrPro-It.otf

sed -Ei '/DeclareFontFamily/s/\}\{[^}]*\}$/}{\\skewchar\\font255 }/g' $(kpsewhich --expand-var '$TEXMFLOCAL')/tex/latex/GaramondPremierPro/OML*.fd

\documentclass{article}

\usepackage[OML,OT1]{fontenc}
\usepackage[utf8]{inputenc}
\renewcommand*{\rmdefault}{GaramondPremierPro-LF}

\DeclareSymbolFont{operators}{OT1}{GaramondPremierPro-LF}{m}{n}
\SetSymbolFont{operators}{bold}{OT1}{GaramondPremierPro-LF}{b}{n}

\DeclareSymbolFont{letters}{OML}{GaramondPremierPro-LF}{m}{it}
\SetSymbolFont{letters}{bold}{OML}{GaramondPremierPro-LF}{b}{it}

\begin{document}

$ \dot A \dot B \dot C \dot D \dot E \dot F \dot G \dot H \dot I
  \dot J \dot K \dot L \dot M \dot N \dot O \dot P \dot Q \dot R
  \dot S \dot T \dot U \dot V \dot W \dot X \dot Y \dot Z $

$ \dot a \dot b \dot c \dot d \dot e    -   \dot g \dot h \dot \imath (i)
     -   \dot k \dot l \dot m \dot n \dot o    -   \dot q \dot r
  \dot s \dot t \dot u \dot v \dot w \dot x    -   \dot z $

$ \dot f \dot \jmath (j) \dot p \dot y $ - heuristic skew from .fd (otftotfm)

$ \skew{0}{\dot}{f} \skew{0}{\dot}{\jmath} (j)
  \skew{0}{\dot}{p} \skew{0}{\dot}{y} $ - no skew?

$ \skew{10}{\dot}{f} \skew{4}{\dot}{\jmath} (j)
  \skew{4}{\dot}{p} \skew{4}{\dot}{y} $ - skew with same values (except f)

\end{document}

Hi,
We have got 4 bug reports in Debian that various tools shipped by lcdf-typetools crashed during some tests. The BTS involves some crash data. Instead of filing 4 different reports I'm filing this one report and placing links to Debian BTS which contains crash data.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715722
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716221
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716370
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716371
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716404

It seems that otfinfo does not support .ttc (TrueType Collection) files, does it? If not, please do. Thanks.

texlive2017 evidently removes support for updmap, instead requiring either updmap-sys or updmap-user. ("These scripts work in one of two modes: user or sys(tem) mode. If no mode is specified, a warning is printed. (This is as of TeX Live 2017, when the -user variants were created; before that, the script name without a suffix was the user variant.)" http://tug.org/texlive/scripts-sys-user.html) How can I get otftotfm -a to call that?

otftotfm -a -e texnansx --typeface "adobetext" --vendor "adobe" "AdobeTextPro-Regular.otf" -flnum -fkern -fliga  LY1-AdobeTextPro-Regular-lnum-kern-liga
I had to round some heights by 19.0000000 units.
I had to round some depths by 5.0000000 units.
I had to round some heights by 19.0000000 units.
I had to round some depths by 5.0000000 units.
otftotfm: warning: 'updmap --nomkmap --enable Map adobe.map >/dev/null 2>&1; updmap >/dev/null 2>&1' exited with status 1;
otftotfm: warning: run it manually to check for errors
texhash: /opt/local/etc/texmf: directory not writable. Skipping...
texhash: /opt/local/share/texmf: directory not writable. Skipping...
texhash: /opt/local/share/texmf-local: directory not writable. Skipping...
texhash: /opt/local/share/texmf-texlive: directory not writable. Skipping...
texhash: /opt/local/var/db/texmf: directory not writable. Skipping...
texhash: Done.
updmap [ERROR]: Either -sys or -user mode is required.
updmap [ERROR]: In nearly all cases you should use updmap -sys.
updmap [ERROR]: For special cases see http://tug.org/texlive/scripts-sys-user.html

Would be helpful if otfinfo could report on "embeddable flags" as documented at https://docs.microsoft.com/en-us/typography/opentype/spec/os2#fstype (and at https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6OS2.html for Truetype).

$ otfinfo -u unifont-7.0.06.ttf
otfinfo: unifont-7.0.06.ttf: bad glyph name index in post
Assertion failed: ((unsigned) i < (unsigned) _n), function operator[], file ./../include/lcdf/vector.hh, line 66.
Abort trap: 6

unifont is freely available from here: http://unifoundry.com/unifont.html

Compiling lcdf-typetools-2.104 (as p part of the TeXLive 2015 tree) on Solaris 11 with Studio 12.4 compiler fails with:

"../../../../../texk/lcdf-typetools/lcdf-typetools-2.104/otfinfo/otfinfo.cc", line 427: Error: Overloading ambiguity between "String::String(bool)" and "String::String(const String&)".
1 Error(s) detected.

Often times, there is a glyph one might want that doesn't exist with it's own slot in the font itself. Unfortunately, using LaTeX to create accented characters has serious drawbacks: not the least of which is that it's impossible to create characters with double diacritics without extra packages and manual tweaking. Furthermore, this doesn't take advantage of OpenType's advanced positioning features to achieve optimal results. What I am looking for is some sort of feature wherein you specify a character and one or more combining characters, and otftotfm would then synthesize this character and put it in whatever slot specified.

The recently changed otffvar.cc indiscriminately makes use of the C++11 keyword nullptr. This breaks the i386-linux build of TeX Live: https://github.com/TeX-Live/texlive-source/actions/runs/6043477466/job/16400552260

See also this thread: https://tug.org/pipermail/tlbuild/2023q3/005341.html

The web page http://www.lcdf.org/type/ lists official Debian packaging. Thanks for that!

It lists C.M. Connelly as maintainer, however, which was true for quite some time - 2003-2012 - but since then Vasudev Kamath and I have taken over, and nowadays mostly I care for that package.

Instead of trying to keep track of who does what when in Debian, you might want to instead (like done in Mac OS X section) link to "Packages" at the (redirection) page https://packages.debian.org/lcdf-typetools (instead of the current link to only testing release) and maybe additionally link to "Developer info" at https://tracker.debian.org/pkg/lcdf-typetools.

Thanks for considering - and for developing this nice project and licensing it freely!

The scripts in the showings subdirectory create PDFs displaying some OpenType features by using payware fonts, which are not easily available to many users.

It would be nice to include demo PDFs which use OpenSource OTF fonts, such as one from the FiraSans family (created by The Mozilla Foundation and Telefonica S.A.), Source Sans Pro (created by Adobe) or Linux Libertine.

This have the additional advantage that they also could demonstrate Stylistic Set (ss01, ss02 and ss03) features.

Variable otf fonts are often not very well documented. LuaTeX has started supporting them, however the names of the axes and the boundaries of variation need to be known. Having otfinfo provide this data would be quite useful.

Hi Eddie - TL only has two patches for lcdf-typetools. They both relate to incarnations of Windows, so I know nothing about them, sorry. I also don't know if Akira has a github account, but I'll ask him.

The two patches are here (on the github mirror, I suppose might be easier for you to look at): https://github.com/TeX-Live/texlive-source/tree/trunk/texk/lcdf-typetools/TLpatches

Thanks,
Karl

A few changes have been lingering near HEAD of the git for almost a year now.

Are they for some reason considered unstable? If not, then please consider issuing a new release.

lcdf-typetools defines a static_assert macro that has 1 parameter. This appears to conflict with the standard static_assert which is supposed to have 2 parameters, causing a build failure ("too few arguments provided to function-like macro invocation") when the standard static_assert is available. See MacPorts ticket 40798.

The included glyphlist.txt is an old version with licensing arguably not compliant with Debian Free Software Guidelines. Please replace with the newer relicensed file from https://github.com/adobe-type-tools/agl-aglfn to ease redistribution.

I was trying to compile lcdf-typetools with MinGW-w64's gcc compiler on MSYS2.

But The build fails with

otftotfm/automatic.cc:46:29: error: '_mkdir' was not declared in this scope
 # define mkdir(dir, access) _mkdir(dir)
                             ^

I checked the contents and the file otftotfm/automatic.cc contains the following code:

 #ifdef WIN32
 #ifdef _MSC_VER
 # include <io.h>
 # include <direct.h>
#endif
 # define mkdir(dir, access) _mkdir(dir)
 # define COPY_CMD "copy"
 # define CMD_SEP "&"

This is problematic when using a non-VisualStudio compiler because WIN32 is defined, but _MSC_VER is not, so the required headers are not included. According to https://stackoverflow.com/a/14199731/585897:

Both are specified in io.h, but i guess its better to include direct.h instead (includes io.h in its part).

If I include direct.h outside of #ifdef _MSC_VER (with other words that might mean completely removing the inner ifdef anyway), then it works. It's not exactly clear to me when one would want to avoid including any headers and I don't have cygwin to test, but the header is definitely missing when compiling on MSYS2.

Hi,
This bug was reported in Debian BTS. Which says the file libefont/t1fontskel.cc contains non free adobe code for hinting. I verified and found it as a variable assigned with non free adobe hinting lines / license. But my friend and co-maintainer of package @jonassmedegaard says

tool distributes non-DFSG code embedded as template code for others to compile
 when creating fonts with this tool
 ...and distributing non-DFSG code is forbidden, no matter if compiled or not

So I'm unsure how to deal with this bug, so can you please provide your views on this?.

Cheers,