Hi Arthur and Thomas,
i've put the greek file in the distribution (fea path), do we also need
this babel stuff for u and such?
we should start thinking about a set of predefined features
Hans
-
Arthur Reutenauer wrote:
As a far as I understand, this
behaviour is actually compliant with the Opentype specifications and is
quite widespread among typesetting engines and so it is not (only)
Fontforge's fault; but, needless to say, it is nevertheless
Hi guys,
Try this ordering:
lookup GreekBabelLookupMultiple {
...
} GreekBabelLookupMultiple ;
lookup GreekBabelLookupSimple {
...
} GreekBabelLookupSimple ;
Best wishes,
Taco
___
If your question
Try this ordering:
Yes, it works. So Fontforge is sensitive to the order in which the lookups
are defined in the file? Interesting ...
Thomas, you can try this but I have made a mistake in the Unicode code
for omega with subscribed iota: it should be 1FF3 and not 1FD3.
Arthur
On Sep 16, 2007, at 3:08 PM, Arthur Reutenauer wrote:
Yes, it works. So Fontforge is sensitive to the order in which the
lookups
are defined in the file? Interesting ...
Thomas, you can try this but I have made a mistake in the Unicode
code
for omega with subscribed iota: it should
Hi Arthur, Taco,
you're my heroes! Changing the order of the lookup tables in the .fea
file actually took care of the problem. Thanks for looking into this,
now I get the results I was expecting; every substitution is applied
to the font! Once the initial lookup has been done, this is
Thomas A. Schmitz wrote:
Hi Arthur, Taco,
you're my heroes! Changing the order of the lookup tables in the .fea
file actually took care of the problem. Thanks for looking into this,
now I get the results I was expecting; every substitution is applied
to the font! Once the initial
there were a couple of problems that I just
couldn't resolve, especially regarding the characters with an iota
subscript:
Indeed. This is a problem with the Fontforge code applying the GSUB
features: the 'grbl' feature is defined by two lookups, one being a list
Arthur Reutenauer wrote:
Hello Thomas,
I was waiting for someone else to answer your questions because I
had no clue how to address them even if I was interested; but now I do,
thanks to Hans' reply:
For your general problem you need to define a new regime that will
map each
Hi Arthur,
first of all: thank you so much for your time and your expertise!
Your reply and your scripts really make things a lot clearer for me;
this is a huge step forward! I'll have to experiment and think more
about it, here's just a few reactions to some of your remarks:
On Sep 13,
Right
now, on my system (OS X 10.4), only Adobe Reader 8.0 does copy-paste
correctly, and it does it correctly no matter if I use babel or
Unicode input.
You mean with LuaTeX? Copypasting isn't supported yet in LuaTeX so
it's
Arthur Reutenauer wrote:
Yes, except that we need a more powerful version (almost like OTPs) if
we want to handle transcriptions properly. The vital point is that it
should operate on tokens, not on nodes.
Yes, sure. OTP would work fine here, but I thought Mark IV had already
something
On Sep 13, 2007, at 12:49 PM, Arthur Reutenauer wrote:
You mean with LuaTeX? Copypasting isn't supported yet in LuaTeX so
it's no surprise that it wouldn't work (for me Adobe Reader and
Preview
fail in two different ways). As for pdfTeX I leave that to Taco and
others to answer.
On Sep 13, 2007, at 1:38 PM, Taco Hoekwater wrote:
Arthur Reutenauer wrote:
Yes, except that we need a more powerful version (almost like
OTPs) if
we want to handle transcriptions properly. The vital point is
that it
should operate on tokens, not on nodes.
Yes, sure. OTP would work
Arthur Reutenauer wrote:
Right
now, on my system (OS X 10.4), only Adobe Reader 8.0 does copy-paste
correctly, and it does it correctly no matter if I use babel or
Unicode input.
You mean with LuaTeX? Copypasting isn't
Taco Hoekwater wrote:
Yes, except that we need a more powerful version (almost like OTPs) if
we want to handle transcriptions properly. The vital point is that it
should operate on tokens, not on nodes. I am not sure if Hans already
has a hook there that can be extended.
there are hooks, but
Thomas A. Schmitz wrote:
For your general problem you need to define a new regime that will
map each relevant character sequence to the corresponding Unicode
character. That is, you inform ConTeXt that the character stream
it sees
is actually a way of coding another set of characters
I played a bit, see attachment. Surely Hans will want to improve on this
interface, so don't patch any of the core files just now.
Fantastic!
Now I played a bit with your file myself, and compared with the
behaviour of an OTP which has the same action: you can see that macros
arguments
Arthur Reutenauer wrote:
I played a bit, see attachment. Surely Hans will want to improve on this
interface, so don't patch any of the core files just now.
Fantastic!
Now I played a bit with your file myself, and compared with the
behaviour of an OTP which has the same action: you
Arthur Reutenauer wrote:
... greek ... greek ...
new beta
\defineremapper[babelgreek]
\remapcharacter[babelgreek][`a]{\alpha}
\remapcharacter[babelgreek][`b]{\beta}
\remapcharacter[babelgreek][`c]{\gamma}
\remapcharacter[babelgreek][`d]{OEPS}
\starttext
[\startbabelgreek
a b c some stuff
Arthur Reutenauer wrote:
for arthur ... [] are skipped
Thanks! I guess there's more to it and token filtering is not the only
way to do it, but it's still great.
indeed, also, its' important to look fresh at these things an dforget
about how we do things now, else we replace hack with
On Sep 13, 2007, at 9:45 PM, Arthur Reutenauer wrote:
Thanks! I guess there's more to it and token filtering is not the
only
way to do it, but it's still great.
Arthur
Oh boy... I'm afraid I lost you there. Hans, your remapper looks just
like the thing I'd need for my Greek
Hans Hagen wrote:
Thomas A. Schmitz wrote:
Taco, one question: Hans mentioned that support for wide postscript
fonts via afm was not supported yet. Does that mean that type 1 fonts
with a unicode encoding do not work yet?
the latest mkiv works ok with wide fonts, the latest luatex
indeed, also, its' important to look fresh at these things an dforget
about how we do things now, else we replace hack with hack
Sure, of course. I only thought this was a nice way of handling things
but I'm not settled on that.
Arthur
Hello Thomas,
I was waiting for someone else to answer your questions because I
had no clue how to address them even if I was interested; but now I do,
thanks to Hans' reply:
For your general problem you need to define a new regime that will
map each relevant character sequence to
OK, the message below didn't get too many responses, so maybe I can
rephrase my quiestions in a more precise manner:
1. For otftotfm, there's the unicoding command where you can
replace a character in a certain slot with another unicode character,
so you could say
unicoding A = uni03D1
Is
Thomas A. Schmitz wrote:
OK, the message below didn't get too many responses, so maybe I can
rephrase my quiestions in a more precise manner:
1. For otftotfm, there's the unicoding command where you can
replace a character in a certain slot with another unicode character,
so you could
Hi all,
I've been experimenting with my Greek stuff in luatex, and I think
I'm making nice progress. Things pretty much work with Unicode input,
and as soon as the kerning problem is solved, I'm very optimistic.
Two questions came up for me; I assume the answers are
straightforward, but
28 matches
Mail list logo
