[gentium-commits] [SCM] gentium updated: r96 - trunk/gentium/source/fonts/gentium-tug/type1

[Pavel Far??]

Author: pavel
Date: 2022-04-26 17:47:25 +0000 (Tue, 26 Apr 2022)
New Revision: 96

Modified:
   trunk/gentium/source/fonts/gentium-tug/type1/kerncorrection.py
Log:
add some ideas for improvement to kerncorrection.py

Modified: trunk/gentium/source/fonts/gentium-tug/type1/kerncorrection.py
===================================================================
--- trunk/gentium/source/fonts/gentium-tug/type1/kerncorrection.py	2022-04-26 15:51:56 UTC (rev 95)
+++ trunk/gentium/source/fonts/gentium-tug/type1/kerncorrection.py	2022-04-26 17:47:25 UTC (rev 96)
@@ -33,13 +33,36 @@
 # TODO: refactor the script; maybe remove classes
 
 
-# TODO Decide if should be used purely class-based kerning.
+# TODO: Decide if should be used purely class-based kerning.
 
+# TODO: It might be good idea to split this script into two scripts (Latin and
+#       Cyrillic). It would be better to do different kerning for roman and
+#       italic styles (at least for the small Cyrillic letters; especially
+#       de, el, ge). It would be even better to do manual kerning, but it would take
+#       much time. But I could do support for files with manual kerning. These
+#       files would be used if they were present. This would be similar to the
+#       files that are used for manual kerning for letters dcaron and lcaron.
+#       There shoud be probably three such files for each font (Latin, Greek,
+#       Cyrillic).
+
 # The script currently combines class-based kerning and deriving kerning from list
 # of kerns. Changing it to completely class-based kerning would create more kerning
 # pairs than now. The current (mixed) sollution makes it possible to make exceptions
 # to class-based kerning.
 
+# TODO: It might be good idea to find out which kerning pairs can really occur for
+#       e.g. encoding T1. Pure class-based kernig would give too many kerning pairs.
+#       This is probably no problem for TeX, but it means too many kerning pairs
+#       that would never be needed (and it would be more work to look at the changes
+#       from the original fonts). The solution would be to look for languages that
+#       are supported by T1 and take only those pairs where both the letter are in
+#       the same language. Even this would be a superset of what is really possible.
+#       For example Czech has letters dcaron and ecaron, but the pair
+#       dcaron + ecaron can never occur.
+#
+#       These pairs might be useful also for other fonts for TeX.
+
+
 import os, sys, re
 
 import collections