Kerning on metrics window and +

--===============8218947861595203599==
Content-Type: multipart/alternative; boundary="000000000000676903061a7fcf84"

--000000000000676903061a7fcf84
Content-Type: text/plain; charset="UTF-8"

Hi there.
A few missing features and bugs I want to report:

I am finishing a font on FontForge, which I'll publish for free later, and
I had a few problems:

1 - I have over 5000 classes to kern but I can't just produce all those
pairs and paste them to the metrics window to scroll through them while
adjusting the horizontal kerning, because, apparently, FontForge tries to
render the whole string for every screen refresh, what causes it to be
really slow, making it impossible to work. If it had a scroll system with
no beginning or end, and it only rendered the part of the string that is
showing, it would be totally possible and practical. Instead I had to
produce a PDF of all the pairs in only one line to keep selecting small
portions of if at a time and pasting them to the metrics window, which
takes way longer, skipping pairs because of the break. As the pdf viewer
only renders the part that is showing on the screen, I can scroll through
the pairs pretty quickly.

2 - FontForge's auto-kern feature for individual pairs, with the option
"touching" and with "default separation" set to 0, for some reason produces
most of the pairs touching each other, as it should, but some pairs are
produced with a wrong distance, far apart and not touching. If it produced
all the pairs at the correct distance, with a kerning value just enough for
the glyphs to touch, it would save me a year of extra work.

3 - It seems that FontForge's tool for changing the weight of a glyph
doesn't really work properly, producing erroneous curves and coordinates.
Perhaps you could take the code from InkScape's "Offset" feature from its
window "Path -> Path Effects", and convert it to work with FontForge's
coordinate system. Those InkScape transformations always seemed to work
fine. And the idea is to, of course, make it possible to change the weight
of all the font's glyphs with just one command. FontLab has 2 algorithms
for weight change that also work really well, but since its source is
closed, we are probably not going to be able to get access to it.

4 - There are some minor bugs that I occasionally encounter during the
utilization of the program, but nothing of too much concern. One thing
though that I couldn't figure out was a .ttf font that wasn't displaying
kerning information on any editor, and when I opened it on FontForge it
said that the font contained both a "GPOS" table and a "Kern" table, and
that the Kern table would only be considered if there was no kerning
information on the "GPOS" table. At the "font info" I could access the GPOS
tab with the lookups and all the kerning tables but could not get the pairs
in them to display on the metrics window or at the editor when I generated
the font. And I have no idea what FontForge meant by this warning message
or how to delete this "GPOS" table to make the kerning be read. One other
thing I couldn't figure out is how to lock the width of a glyph(when the
padlock shows near the right bearing), or how to lock the width of a
composite glyph to its base glyph width, without having to delete the glyph
and paste the reference again. But I guess that would be asking for too
much.

Best regards. Thales Martins.

--000000000000676903061a7fcf84
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi there.<div>A few missing features and bugs I want to re=
port:</div><div><br></div><div>I am finishing a font on FontForge, which I&=
#39;ll publish for free later, and I had a few problems:</div><div><br></di=
v><div>1 - I have over 5000 classes to kern but I can&#39;t just produce al=
l those pairs and paste them to the metrics window to scroll through=C2=A0t=
hem while adjusting the horizontal kerning, because, apparently, FontForge =
tries to render the whole string for every screen refresh, what causes it t=
o be really slow, making it impossible to work. If it had a scroll system w=
ith no beginning or end, and it only rendered the part of the string that i=
s showing, it would be totally possible and practical. Instead I had to pro=
duce a PDF of all the pairs in only one line to keep selecting small portio=
ns of if at a time and pasting them to the metrics window, which takes way =
longer, skipping pairs because of the break. As the pdf viewer only renders=
 the part that is showing on the screen, I can scroll through the pairs pre=
tty quickly.</div><div><br></div><div>2 - FontForge&#39;s=C2=A0auto-kern fe=
ature for individual pairs, with the option &quot;touching&quot; and with &=
quot;default separation&quot; set to 0, for some reason produces most of th=
e pairs touching each other, as it should, but some pairs are produced with=
 a wrong distance, far apart and not touching. If it produced all the pairs=
 at the correct distance, with a kerning value just enough for the glyphs t=
o touch, it would save me a year of extra work.</div><div><br></div><div>3 =
- It seems that FontForge&#39;s=C2=A0tool for changing the weight of a glyp=
h doesn&#39;t really work properly, producing erroneous curves and coordina=
tes. Perhaps you could take the code from InkScape&#39;s &quot;Offset&quot;=
 feature from its window &quot;Path -&gt; Path Effects&quot;, and convert i=
t to work with FontForge&#39;s coordinate system. Those InkScape transforma=
tions always seemed to work fine. And the idea is to, of course, make it po=
ssible to change the weight of all the font&#39;s glyphs with just one comm=
and. FontLab has 2 algorithms for weight change that also work really well,=
 but since its source is closed, we are probably not going to be able to ge=
t access to it.</div><div><br></div><div>4 - There are some minor bugs that=
 I occasionally encounter during the utilization of the program, but nothin=
g of too much concern. One thing though that I couldn&#39;t figure out was =
a .ttf font that wasn&#39;t displaying kerning information on any editor, a=
nd when I opened it on FontForge it said that the font contained both a &qu=
ot;GPOS&quot; table and a &quot;Kern&quot; table, and that the Kern table w=
ould only be considered if there was no kerning information on the &quot;GP=
OS&quot; table. At the &quot;font info&quot; I could access the GPOS tab wi=
th the lookups and all the kerning tables but could not get the pairs in th=
em to display on the metrics window or at the editor when I generated the f=
ont. And I have no idea what FontForge meant by this warning message or how=
 to delete this &quot;GPOS&quot; table to make the kerning be read. One oth=
er thing I couldn&#39;t figure out is how to lock the width of a glyph(when=
 the padlock shows near the right bearing), or how to lock the width of a c=
omposite glyph to its base glyph width, without having to delete the glyph =
and paste the reference again. But I guess that would be asking for too muc=
h.</div><div><br></div><div>Best regards. Thales Martins.</div></div>

--000000000000676903061a7fcf84--


--===============8218947861595203599==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============8218947861595203599==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
fontforge-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fontforge-devel
http://fontforge.10959.n7.nabble.com/Developer-f3.html

--===============8218947861595203599==--