TeX in C++
Kasper Peeters
Following up on the WYSIWYG TeX thread and the various discussions
about whether TeX is dying, I'd like to mention that I've taken up the
task to revive CommonTeX (the C implemention of TeX written by Pat
Monardo, from scratch rather than from a Web2C conversion). See
http://www.damtp.cam.ac.uk/user/kp229/tex++/
for more information and motivation. It's in development right now,
but it compiles with a C++ compiler, is a true Unix program in sense
that it reads from stdin, writes output (dvi) to stdout and logging to
stderr, has command line options for page geometry and some other new
features.
Suggestions and discussion are welcome.
Kasper
Graham Douglas
Kasper Peeters <K.Pe...@damtp.cam.ac.uk> wrote in message
news:vbor8luqp...@pauli.amtp.cam.ac.uk...
Kasper, I'd just like to add my words
of encouragement in your efforts to do this.
Keep up the good work -- I agree with many
of the sentiments expressed on your web site.
Others here will too, I'm sure, be interested
to read of your work.
Good luck + all the best in your efforts.
Regards
Graham
M. Shell
>
> Following up on the WYSIWYG TeX thread and the various discussions
> about whether TeX is dying, I'd like to mention that I've taken up the
> task to revive CommonTeX (the C implemention of TeX written by Pat
> Monardo, from scratch rather than from a Web2C conversion). See
>
Kasper,
I like your work too! It is very nice to have TeX as a clean
UNIX application.
Can I ask if you feel that there is anything in particular that
you think that C++'s object oriented features can be used to
enhance TeX in way that was not (easily) possible before?
(I am just wondering about any of the more advanced ideas
you might be thinking about.)
I do have problem getting the code to compile on my Red Hat
6.0 Linux machine.
I am using:
gcc, g++ 2.96
make 3.79
The compilation error that I get is:
g++ -O2 -Wall -c -o tex.o tex.c
tex.c: In function `int main (int, char **)':
tex.c:152: parse error before `&'
tex.c:154: Internal error #122.
tex.c:154: Internal compiler error in finish_function, at
../gcc/cp/decl.c:14422
Please submit a full bug report.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make[1]: *** [tex.o] Error 1
make[1]: Leaving directory `/home/mshell/LATEX/TEX++/UPZ/texpp/src'
make: *** [program] Error 2
Now gcc did croak, but the code around that area looks a bit strange
to me, especially the "&":
catch(std::exception& ex) {
std::cerr << "Abort: " << ex.what() << std::endl;
}
but, it has been awhile since I coded my last try/catch block. It could
be a gcc problem, but it is rare to catch gcc in error (outside of
Linux kernel work).
Thanks for the project,
Mike Shell
Kasper Peeters
> gcc, g++ 2.96
>
> tex.c:154: Internal compiler error in finish_function, at
> ../gcc/cp/decl.c:14422
> Please submit a full bug report.
As it says, this is a compiler error. Upgrade your compiler, the code
is fine.
Kasper
Maurizio Loreti
> I am using:
> gcc, g++ 2.96
gcc 2.96 does not exist; see e.g. http://gcc.gnu.org/gcc-2.96.html .
It is an extremely buggy invention of RedHat. Install gcc 3.0.4 (or
wait for 3.1, announced for mid-april).
--
Maurizio Loreti http://www.pd.infn.it/~loreti/mlo.html
Dept. of Physics, Univ. of Padova, Italy loreti at pd dot infn dot it
M. Shell
>
>
> gcc 2.96 does not exist; see e.g. http://gcc.gnu.org/gcc-2.96.html .
> It is an extremely buggy invention of RedHat. Install gcc 3.0.4 (or
> wait for 3.1, announced for mid-april).
>
Kasper and Maurizio,
Thanks for the advice. This would explain some problems I had
been getting recently when trying to compile a new glibc.
But, 2.96 may not be so bad after all. GNU really dropped the
ball in the early 2.85 releases and early releases of 3.0 were
even more buggy than 2.96. Red Hat's 2.96 is just snap
shots of the gcc 3.0 development - with maybe some extra fixes.
For another take on the matter, see:
http://www.bero.org/gcc296.html
Now, I had been using 2.96 release 69, so I upgraded
to 2.96 release 109. 109 is very recent - March 26, 2002.
I can compile an entire glibc 2.2.5 without any problem.
Trying to build TeX++ again, gcc/g++ (109) does not croak, but still
does not like what it sees:
g++ -O2 -Wall -c -o tex.o tex.c
tex.c: In function `int main (int, char **)':
tex.c:152: parse error before `&'
tex.c:154: confused by earlier errors, bailing out
make[1]: *** [tex.o] Error 1
make[1]: Leaving directory `/home/mshell/LATEX/TEX++/UPZ/texpp/src'
make: *** [program] Error 2
Now, _maybe_ you are right, and the code is correct, but this
pretty much means that no one in the entire Red Hat 7.0, 7.1,
or 7.2 series will be able to compile TeX++.
If it is just that one line, it might be a good idea to put in
a little work around, because that is a lot of compilers that
seem to be locked out by it.
What are you guys using to compile TeX++ ?
Thanks,
Mike
Maurizio Loreti
(http://www.damtp.cam.ac.uk/user/kp229/tex++/#download) you may read:
* A decent C++ compiler; gcc 3.x and higher will do.
I assume that gcc 2.96 is just a "not decent compiler", sorry; you are
of course free to dissent :-) I tought about downloading TeX++ and
compiling with 3.0.4 but, sorry, I have work to do and will be away
from my computer from tuesday afternoon up to April 17 :-( If I may
stole some time for this, I'll let you know...
Maurizio Loreti
> FWIW, in the download page
> (http://www.damtp.cam.ac.uk/user/kp229/tex++/#download) you may read:
>
> * A decent C++ compiler; gcc 3.x and higher will do.
>
> I assume that gcc 2.96 is just a "not decent compiler", sorry; you are
> of course free to dissent :-) I tought about downloading TeX++ and
> compiling with 3.0.4 but, sorry, I have work to do and will be away
> from my computer from tuesday afternoon up to April 17 :-( If I may
> stole some time for this, I'll let you know...
I follow up to my message because it was damn easy to track the only
error. I have downloaded texpp, run ./configure, then make; I got an
error compiling src/eval.c, saying that the procedure "abs" was not
declared; I have added an #include <cstdlib> in src/eval.c; after a
second command "make", g++ 3.0.4 has compiled the source files and
linked the executable without any further problem.
I do not know what you intend with "release number of gcc 2.96"; I
assume that this is a RedHat internal number. I *again* **STRONGLY**
advise against using non official, declared buggy by the same gcc
developers, versions built by unknown people and distributed under a
name, gcc, that in my not-so-humble opinion (being a programmer from
1968) is *stolen*. Only gcc developers may distribute gcc releases.
Period.
I use only official distributions downloaded from gcc.gnu.org;
bootstrapped and installed after a VERY CAREFUL reading of the
installation instructions; and I never had a problem with gcc. Why
not to do the same?
May the force be with you...
David Kastrup
> I do not know what you intend with "release number of gcc 2.96"; I
> assume that this is a RedHat internal number. I *again* **STRONGLY**
> advise against using non official, declared buggy by the same gcc
> developers, versions built by unknown people and distributed under a
> name, gcc, that in my not-so-humble opinion (being a programmer from
> 1968) is *stolen*. Only gcc developers may distribute gcc releases.
> Period.
gcc is mainly developed by Cygnus, which is owned by RedHat. So
talking about RedHat "stealing" from itself is pretty strange.
However, they have kept their noninterference to such a level that
people don't see their involvement with gcc, and that Cygnus
employees and other gcc developerts can get surprised by RedHat's
moves.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David....@t-online.de
Travis Casey
> Maurizio Loreti <mlo...@pd.infn.it> writes:
>> distributed under a name, gcc, that in my not-so-humble opinion
>> (being a programmer from 1968) is *stolen*. Only gcc developers may
>> distribute gcc releases.
>
> Hmm. I thought that gcc was free software, so everybody would have
> the right to modify the sources and freely distribute those modified
> versions?
Well... not quite. They're free to do that *if* they follow the
restrictions of the GPL. However, I don't see anywhere that the RedHat
folks broke it. If they had, I'm sure the FSF would be all over them.
--
ZZzz |\ _,,,---,,_ Travis S. Casey <efi...@earthlink.net>
/,`.-'`' -. ;-;;,_ No one agrees with me. Not even me.
|,4- ) )-,_..;\ ( `'-'
'---''(_/--' `-'\_)
M. Shell
>
> I think there's an
>
> #include <exception>
>
> statement missing in that file.
>
Bingo!
That fixed it right up for me. No problems with 2.96-109,
it will probably compile with 2.96-69 as well.
Are you saying that if the source files ended in .cpp, there
would be no need for this include? If so, I wonder why as the
make file did call gcc via g++, so it should already have
defaulted to the C++ language.
I didn't need Maurizio's #include <cstdlib>, but other systems
might.
For those of you who are interested, those release numbers
correspond to the rpm package that installed them. I've
been using rpm for gcc upgrades, but I compile my own glibc
and kernels.
Details of gcc rpms can be seen at:
http://www.rpmfind.net/linux/rpm2html/search.php?query=gcc&submit=Search+...&system=&arch=
The relationship between Red Hat and gcc is the second FAQ question at:
http://www.gnu.org/software/gcc/faq.html
Thanks for the help!
Mike
Maurizio Loreti
> Maurizio Loreti <mlo...@pd.infn.it> writes:
>
> > distributed under a name, gcc, that in my not-so-humble opinion
> > (being a programmer from 1968) is *stolen*. Only gcc developers may
> > distribute gcc releases.
>
> Hmm. I thought that gcc was free software, so everybody would have
> the right to modify the sources and freely distribute those modified
> versions?
This may be true; BUT, if I am distributing software that is intended
to be compiled by gcc, the conclusion is that I am forced to specify
in the README exactly how I define "gcc". If a developer does not
state e.g. "use the gcc program changed and distributed by Bill Gates
or Stefan Ulrich or [insert a name]", I assume that he wants to refer
to The Real Thing --- i.e. to the Free Software Foundation unchanged
distributions. In that particular case, I have noted that the author
EXPLICITELY names gcc 3.* as the version to be used.
Maurizio Loreti
> Well... not quite. They're free to do that *if* they follow the
> restrictions of the GPL. However, I don't see anywhere that the RedHat
> folks broke it. If they had, I'm sure the FSF would be all over them.
I have named the page http://gcc.gnu.org/gcc-2.96.html in this thread.
Did you cared to read? Look:
"GCC 2.96 is not a formal GCC release nor will there ever be such a
release."
"2.96 produce object files that are not compatible with those produced
by either GCC 2.95.2 or ... GCC 3.0 ... [and] these snapshots will not
be compatible with any official GCC release."
"Binaries built using any version of GCC 2.96 ... will not be portable
to systems based on one of our regular releases."
"If you encounter a bug in a compiler labeled 2.96, we suggest you
contact whoever supplied the compiler as we can not support 2.96
versions, that were not issued by the GCC team."
Is that clear enough?
Stefan Baums
The Omega project (more precisely a bunch of John Plaice’s graduate
students at the University of New South Wales) are also busy
reimplementing Omega (the Unicode version of TeX) in C++. Maybe you
should consider teaming up with them. Web page is at
Joining the (low‐volume) mailing list is recommended for getting any
sort of grasp on what’s going on with Omega.
Stefan
--
Stefan Baums
Asien-Instituttet
Københavns Universitet
Kasper Peeters
> The Omega project (more precisely a bunch of John Plaices
> graduate students at the University of New South Wales) are also
> busy reimplementing Omega (the Unicode version of TeX) in C++.
I couldn't find anything about the C++ in the mailing list archives,
perhaps someone can comment on the status of that project.
TeX++, while not a from-the-base-up implementation, has perhaps the
advantage that it is already fully functional (ie. processing tex and
latex documents just fine).
Kasper
David Kastrup
> The Omega project (more precisely a bunch of John Plaice’s graduate
> students at the University of New South Wales) are also busy
> reimplementing Omega (the Unicode version of TeX) in C++. Maybe you
> should consider teaming up with them. Web page is at
>
> http://omega.cse.unsw.edu.au/
>
> Joining the (low‐volume) mailing list is recommended for getting any
> sort of grasp on what’s going on with Omega.
Will all due respect, this looks like about the last thing Omega
needs. What use is there in turning a great program nobody can use
into an even greater program nobody can use?
Its current usage interfaces are decidedly less documented and less
accessible to the average user than even plain TeX. A
reimplementation of Omega will not cure this principle obstacle to its
application or more widespread use.
David Kastrup
I looked at its home page a few days ago, and it said that it was not
able to load any format files.
Kasper Peeters
> I looked at its home page a few days ago, and it said that it was not
> able to load any format files.
You can just \input latex.ltx at the beginning of your document and
it'll work fine. It's functional, I never claimed it was finished ;-)
Kasper
Stefan Baums
> I couldn't find anything about the C++ in the mailing list archives,
> perhaps someone can comment on the status of that project.
Sebastian Rahtz on 23 October 2001:
looking through a diff of TeX Live source against Omega, I see a lot
of, eg
/* argument(s) added to function, by team 18 */
who or what is "team 18"? can anyone elucidate?
To which John Plaice replied next day:
Team 18 is a team of students who were working for me this past
year. They did the work to make sure that all of web2c could
compile with the C++ compiler, which is more finicky than the C
compiler. They have also done a lot of recoding of tex.web in C++,
but the work is not yet fully integrated. Coming soon....
As for status, emailing John Plaice <pla...@omega.cse.unsw.edu.au>
seems your best bet or, preferably, asking him on the mailing list.
Stefan Baums
> Will all due respect, this looks like about the last thing Omega
> needs. What use is there in turning a great program nobody can use
> into an even greater program nobody can use?
Can’t one hope? There is very clearly a need for a working Unicode
TeX, and in spite of everything Omega seems to be the closest
approximation.
Believe me, I’m even more frustrated with lack of Omega
(documentation) progress than you because as a non‐programmer there is
very little indeed I can do to help. But don’t you think injecting
new blood into Omega development (Kasper Peeters’ blood...?) might
help?
David Kastrup
> > Will all due respect, this looks like about the last thing Omega
> > needs. What use is there in turning a great program nobody can use
> > into an even greater program nobody can use?
>
> Can’t one hope? There is very clearly a need for a working Unicode
> TeX, and in spite of everything Omega seems to be the closest
> approximation.
I disagree. I see a clear need for a working Unicode LaTeX: a LaTeX
where I can write
\usepackage[utf8]{inputenc}
and that's it, but that will still work without a hitch with older
documents in other encodings by the appropriate declaration.
I think it highly likely that Omega could be used for providing
something like that.
But that's about it. It's theoretical.
> Believe me, I’m even more frustrated with lack of Omega
> (documentation) progress than you because as a non‐programmer there
> is very little indeed I can do to help. But don’t you think
> injecting new blood into Omega development (Kasper Peeters’
> blood...?) might help?
I don't know. My needs for Omega are not as large as to warrant more
than the few hours that I spent trying to figure out how to make use
of it before deciding it was not worth the trouble for me to find a
sensible way of making it work if it had not been worth the trouble
to anybody else, obviously.
Giuseppe Bilotta
>
> I disagree. I see a clear need for a working Unicode LaTeX: a LaTeX
> where I can write
> \usepackage[utf8]{inputenc}
> and that's it, but that will still work without a hitch with older
> documents in other encodings by the appropriate declaration.
>
> I think it highly likely that Omega could be used for providing
> something like that.
>
> But that's about it. It's theoretical.
How usable is Lambda re this? (I also seem to remember some unicode
LaTeX package or something like that (ucs?)).
--
Giuseppe "Oblomov" Bilotta
Axiom I of the Giuseppe Bilotta
theory of IT:
Anything is better than MS
Donald Arseneau
Two candidates for quote of the week:
>Can’t one hope? There is very clearly a need for a working Unicode
>TeX.
>Joining the (low‐volume) mailing list is recommended for getting any
>sort of grasp on what’s going on with Omega.
Donald Arseneau as...@triumf.ca
Torsten Bronger
Giuseppe Bilotta wrote:
> David Kastrup wrote:
>
>>I disagree. I see a clear need for a working Unicode LaTeX: a LaTeX
>>where I can write
>>\usepackage[utf8]{inputenc}
>>and that's it, but that will still work without a hitch with older
>>documents in other encodings by the appropriate declaration.
>>
>>I think it highly likely that Omega could be used for providing
>>something like that.
>>
>>But that's about it. It's theoretical.
>>
>
> How usable is Lambda re this? (I also seem to remember some unicode
> LaTeX package or something like that (ucs?)).
Yes, this unicode package should do it, but first and foremost
PassiveTeX (together with XMLTeX). It's unbelievable how much you can
teach the good old TeX.
However, Omega does a lot more than just mapping unicodes to LaTeX
commands. I must admit that I didn't understand that 'more' either.
Every time when I read an article about a re-implementation I wonder
whether it's good for the TeX babies if they work so independently.
Okay, PS is out, PDF is in. TeX must be easy to be extended. And
Unicode is the answer to the dark era of encoding battles. (Well, one
day at least ;-)
And now we have pdfTeX, NTS and Omega. Super. Instead of
re-implementing every idea in yet another language, one should merge
the ideas.
Tschoe,
Torsten.
Giuseppe Bilotta
> Stefan Baums <ba...@hum.ku.dk> writes:
>
> Two candidates for quote of the week:
>
> >Can’t one hope? There is very clearly a need for a working Unicode
> >TeX.
I guess his newsreader is at fault here.
> >Joining the (low‐volume) mailing list is recommended for getting any
> >sort of grasp on what’s going on with Omega.
Ehehehe :-D
Idris Samawi Hamid
> than the few hours that I spent trying to figure out how to make use
> of it before deciding it was not worth the trouble for me to find a
> sensible way of making it work if it had not been worth the trouble
> to anybody else, obviously.
I will bet a fat man to a dime that I am more
upset/frustrated/disappointed/disenchanted with the slow, closed pace of
Omega development than anyone on CTT, but I don't see how continually
trolling the project:-) helps (as in the "TeX is dying" thread). Despite
minimal documentation and/or help from the omega list I, a philosopher by
profession (and non-programmer), have made huge strides in taking advantage
of Omega's features which r a really valuable addition to TeX's
capabilities. There is no way I could do the kind of Arabic work I do in
TeX/LaTeX. The otp system and 16-bit font support (which is mandatory for
high-quality Arabic fonts), not to mention multi-directional typesetting,
have well "been worth the trouble" and price of admission. EDMAC and
virtually every other package works right out of the box with Omega (though
Lambda is buggy). Through hard work I have managed to learn how to make cfg
files for a new font, build ovf's and ofm's, and get the font working in
Omega. Admittedly it was very painful but u r a programmer, David (unlike
me), so I can't accept your excuse:-)
Instead of waiting for John and Yannis to change their modus operandi, I
wish a few of us would join forces to move things forward. I am willing to
help with documentation based on my own experiences. If a group of us would
just start pushing things forward it may even help spur J & Y to stop
taking Omega's users for granted.
Best wishes
Idris
Idris Samawi Hamid
> If a group of us would
> just start pushing things forward it may even help spur J & Y to stop
> taking Omega's users for granted.
Ok, ok, I admit it: now _I'm_ trolling. But let's call it ``proactive
trolling'' as opposed to ``reactionary trolling" (grin).
Idris
Rich
ish...@netscape.net spake the secret code
<3CB4E708...@attbi.com> thusly:
>Instead of waiting for John and Yannis to change their modus operandi, I
>wish a few of us would join forces to move things forward. I am willing to
>help with documentation based on my own experiences. If a group of us would
>just start pushing things forward it may even help spur J & Y to stop
>taking Omega's users for granted.
My advice: don't wait for the group, just start writing the
documentation based on your own experience now.
--
Ask me about my upcoming book on Direct3D from Addison-Wesley!
Direct3D Book http://www.xmission.com/~legalize/book/
izfree: Open source tools for Windows Installer
http://izfree.sourceforge.net
Giuseppe Bilotta
> And now we have pdfTeX, NTS and Omega. Super. Instead of
> re-implementing every idea in yet another language, one should merge
> the ideas.
I'm one of the stronger supporter of a merge between pdf-e-TeX and
Omega. I'm also a strong supporter of the librarifications of TeX
(splitting the typesetter from the parser and the outputter). I'm also
the promoter of TeXlib (see it on SourceForge). I'm also stupid enough
to not be able to write a small parser acting like TeX token scanner
to start testing the library ... anybody?
Giuseppe Bilotta
> There is no way I could do the kind of Arabic work I do in
> TeX/LaTeX. The otp system and 16-bit font support (which is mandatory for
> high-quality Arabic fonts), not to mention multi-directional typesetting,
> have well "been worth the trouble" and price of admission. EDMAC and
> virtually every other package works right out of the box with Omega (though
> Lambda is buggy). Through hard work I have managed to learn how to make cfg
> files for a new font, build ovf's and ofm's, and get the font working in
> Omega. Admittedly it was very painful but u r a programmer, David (unlike
> me), so I can't accept your excuse:-)
If you were to share this with the community, it would be enormously
appreciated. Just start by putting down the steps. People will come
later to improve/tune your documentation, and possibly even come out
with programs to automate as much as possible of those steps.
David Kastrup
> > I don't know. My needs for Omega are not as large as to warrant more
> > than the few hours that I spent trying to figure out how to make use
> > of it before deciding it was not worth the trouble for me to find a
> > sensible way of making it work if it had not been worth the trouble
> > to anybody else, obviously.
>
> I will bet a fat man to a dime that I am more
> upset/frustrated/disappointed/disenchanted with the slow, closed pace of
> Omega development than anyone on CTT, but I don't see how continually
> trolling the project:-) helps (as in the "TeX is dying" thread). Despite
> minimal documentation and/or help from the omega list I, a philosopher by
> profession (and non-programmer), have made huge strides in taking advantage
> of Omega's features which r a really valuable addition to TeX's
> capabilities.
That's what I say. If using a system at all necessitates making
huge strides, something is amiss. For this reason Omega is not a
choice except for people with requirements that can not be met
otherwise. For those the huge strides pay off.
> Lambda is buggy). Through hard work I have managed to learn how to
> make cfg files for a new font, build ovf's and ofm's, and get the
> font working in Omega. Admittedly it was very painful but u r a
> programmer, David (unlike me), so I can't accept your excuse:-)
It's not an excuse. I am a programmer, so I don't have a need for
Omega's capabilities. You are a philologist, you can't help using
it. If you resent me not using Omega, make it more accessible.
After all, you _have_ figured out how to do this. Cooperate with the
more technically savvy Omega people and come up with something
together instead of complaining others that don't even use Omega do
not do this for you.
Stefan Baums
> I disagree. I see a clear need for a working Unicode LaTeX: a LaTeX
> where I can write
> \usepackage[utf8]{inputenc}
> and that's it, but that will still work without a hitch with older
> documents in other encodings by the appropriate declaration.
Specifying the input encoding to Omega is trivial and does not use the
inputenc package. The proper invocation for UTF‐8 is:
\ocp\MyTexUTF=inutf8
\DefaultInputTranslation onebyte \MyTexUTF
\InputTranslation currentfile \MyTexUTF
at the head of the file, and of course you can define some
abbreviation for this.
What’s really needed is more support and documentation at the font and
OTP (omega translation process) levels. I, e.g., urgently need to use
a largish (> 256 characters) Unicode TrueType font, but can’t find a
way to generate the OFM (corresponding to TeX’s TFM) file that Omega
needs for this to work. At another level of difficulty, it would be
really nice to get OpenType fonts to work with Omega. This could be
accomplished by somehow converting (possibly on the fly) OpenType GSUB
and GPOS tables to OTPs, but that would need substantial programming
skills, I fear.
Stefan Baums
> I guess his newsreader is at fault here.
Hardly. My post is properly encoded as UTF‐8 and displays just fine
in Emacs 21.2.1 / Gnus 5.9.0 as well as in Mozilla 0.9.9, see
screenshots at
http://staff.hum.ku.dk/baums/shot1.png
http://staff.hum.ku.dk/baums/shot2.png
What’s more, I received my hyphens and apostrophes (hardly advanced
features of Unicode...) back ungarbled in at least David Kastrup’s
quote from my post, see
http://staff.hum.ku.dk/baums/shot3.png
You may want to upgrade your newsreader to a less ancient version
and/or configure it properly.
:-)
David Kastrup
> David Kastrup <David....@t-online.de> writes:
>
> > I disagree. I see a clear need for a working Unicode LaTeX: a LaTeX
> > where I can write
> > \usepackage[utf8]{inputenc}
> > and that's it, but that will still work without a hitch with older
> > documents in other encodings by the appropriate declaration.
>
> Specifying the input encoding to Omega is trivial and does not use the
> inputenc package. The proper invocation for UTF‐8 is:
>
> \ocp\MyTexUTF=inutf8
> \DefaultInputTranslation onebyte \MyTexUTF
> \InputTranslation currentfile \MyTexUTF
>
> at the head of the file, and of course you can define some
> abbreviation for this.
You are proving my point. It does not matter whether specifying the
input encoding to Omega is trivial and "does not use" the inputenc
package, in particular when this triviality is documented nowhere.
"and of course" the right abbreviation for this to be defined is
\usepackage[utf8]{inputenc}
That utf8.def would be trivially easy to create makes it a more
glaring omission on the part of Omega's developers.
The user wants to tell Omega he has encoded his document in utf8.
The user does not want to tell Omega to use some OCP in order to
translate stuffs from currentfile into something or whatever else.
That's the _implementation_ of things, and details of the
implementation have nothing to do in a user's invocation.
It's "trivial" stuff like that which makes Omega unusable.
Javier Bezos
> David Kastrup <David....@t-online.de> writes:
>
> > I disagree. I see a clear need for a working Unicode LaTeX: a LaTeX
> > where I can write
> > \usepackage[utf8]{inputenc}
> > and that's it, but that will still work without a hitch with older
> > documents in other encodings by the appropriate declaration.
>
> Specifying the input encoding to Omega is trivial and does not use the
> inputenc package. The proper invocation for UTF‐8 is:
>
> \ocp\MyTexUTF=inutf8
> \DefaultInputTranslation onebyte \MyTexUTF
> \InputTranslation currentfile \MyTexUTF
>
> at the head of the file, and of course you can define some
> abbreviation for this.
Unfortunately it's not so easy like that, except in simple
cases. Actually, ocp's can be used for lots of things and
they must be properly coordinated. Furthermore, there
are some issues in that approach, which works fine
because ascii chars have the same representation in utf8,
but how do you tell Omega that the current file use "windows"
ucs2? (The problem of the hen and the egg.) Or how do
you combine koi8 and uft8 in the same file? Problems like
that (and many more) were discussed in the LaTeX3 list.
Omega needs many improvements, and that's what John
and Yannis are doing. After that, work on developping a
new multilingual interface fully integrated will LaTeX
will be resumed. Part of the discussions about that
is available on
http://www.math.utah.edu:8080/pub/tex/mail/latex-l_20010301.txt
Sadly, I've been unable to find a url with
the full discussion. If someone knows one, please send it
because my Outlook deleted without any warning all the
messages from the LaTeX3 list.
Regards
Javier
___________________________________________________________
Javier Bezos | TeX y tipografia
jbezos at wanadoo dot es | http://perso.wanadoo.es/jbezos/
...........................................................
CervanTeX http://apolo.us.es/CervanTeX/CervanTeX.html
Idris Hamid
Resentment?!? Who said anything about resentment?
I don't resent u; quite to the contrary, I admire your your work and
contributions, and hope to continue benefitting from them (I use your binhex with
Omega to generate code charts for example). As for making Omega more accessible,
I intend to do the best I can; but help and cooperation from other interested
users would certainly help to get it done faster. But I don't blame, let alone
resent, anyone for not using Omega, especially in its present state. I would just
like to see more proactivity---even if its critical proactivity---in this, our
rather small TeX community.
> Cooperate with the
> more technically savvy Omega people and come up with something
> together
Is that not what I've been calling for and trying to do (and I've communicated
with others on the Omega list about this as well)? U're preaching to the choir
here.
> instead of complaining others that don't even use Omega do
> not do this for you.
Now that's certainly NOT what I said. Where did I ask for non-Omega users to do
anything at all for me wrt Omega?
U said:
> of it before deciding it was not worth the trouble for me to find a
> sensible way of making it work if it had not been worth the trouble
> to anybody else, obviously.
I merely gave a counter-example to show that it HAD "been worth the trouble" to
someone else, with the implication that if I could do it, so could u if u really
wanted to (since you r more technically savvy). But the fact that u did not find
it worth the effort does not justify trolling the project in a _reactionary_ way,
IMHO. In fact, I agreed with your criticisms and added a few of my own; I just
think that proactive criticism as well as encouragement of the project is more
useful.
Anyway, email comes across harsher than intended; no offense was intended. The
:-)'s in my earlier mail were meant to bring my points across lightheartedly.
:-):-):-):-):-):-):-):-).......
If anyone with Omega experience wants to help me with helping Omega along, feel
free to email me at ish...@attbi.com or @netscape.net.
Best wishes
Idris
Javier Bezos
> You are proving my point. It does not matter whether specifying the
> input encoding to Omega is trivial and "does not use" the inputenc
> package, in particular when this triviality is documented nowhere.
> "and of course" the right abbreviation for this to be defined is
> \usepackage[utf8]{inputenc}
Or maybe not. Bringing together several languages from
different sources makes the inputenc scheme as used currently
very limited, imo.
> That utf8.def would be trivially easy to create makes it a more
> glaring omission on the part of Omega's developers.
Nope. The code by Stephan Baum only works properly
when placed in the document file and not in a style
file. It's an omission of Omega's developers, indeed,
but things like that are getting fixed.
> The user wants to tell Omega he has encoded his document in utf8.
> The user does not want to tell Omega to use some OCP in order to
> translate stuffs from currentfile into something or whatever else.
Right. Any attempt to develop an user interface for
Omega should hide ocp's. Users should not be aware of
its existence.
> That's the _implementation_ of things, and details of the
> implementation have nothing to do in a user's invocation.
>
> It's "trivial" stuff like that which makes Omega unusable.
What makes Omega unusable is that these trivial stuff is
not trivial at all, except in simple cases. You can use
it, of course, because you can do already pretty things
with Omega, but a consistent user interface must still wait
a little. In fact, some of the limitations of Omega
were discovered when trying to write such an interface.
It's not a short-term work, so don't be anxious... ;-)
Idris Hamid
Please stop spreading nonsense:-) If Omega is "unusable", how on earth am I
and others using it and drawing benefit from it? If u had said ``not very
user-friendly'' or ``needs a high-level interface'' or something similar we
would all agree. But saying that it's ``unusable'' is both untrue and
unhelpful.
For those reading this discussion I can say the following: using Omega for
certain (but by no means all) applications at present requires an
understanding of some low- and mid-level commands, not very hard to grasp,
which you can can roll up into your own sty file or preamble. Not for the
faint-at-heart, but neither is TeX:-)
Best wishes
Idris
Rich
Stefan Baums <ba...@hum.ku.dk> spake the secret code
<87wuvec...@hum.ku.dk> thusly:
>My post is properly encoded as UTF‐8 [...]
Well, I would disagree with that assertion. I don't believe that one
should assume that news messages are 8-bit clean because news messages
may still be transported through 7-bit mail channels. Your message
uses unencoded 8-bit bytes and IMO should be encoded with
printed-quotable.
Of course, I'm not really sure why UTF-8 is needed to send non-ASCII
representations for the "'" character, which seems to be all that is
happenning in these messages sent as UTF-8.
Giuseppe Bilotta
> Giuseppe Bilotta <obl...@freemail.it> writes:
>
> > I guess his newsreader is at fault here.
>
> Hardly. My post is properly encoded as UTF‐8 and displays just fine
> in Emacs 21.2.1 / Gnus 5.9.0 as well as in Mozilla 0.9.9, see
> screenshots at
>
> http://staff.hum.ku.dk/baums/shot1.png
> http://staff.hum.ku.dk/baums/shot2.png
>
> What’s more, I received my hyphens and apostrophes (hardly advanced
> features of Unicode...
It's not a matter of how advanced are they but on which plane they
are, and how many bytes does it take to encode them.
> ) back ungarbled in at least David Kastrup’s
> quote from my post, see
>
> http://staff.hum.ku.dk/baums/shot3.png
>
> You may want to upgrade your newsreader to a less ancient version
> and/or configure it properly.
I'd like to, but Gravity does not have `less ancient´ versions that
the one I'm using, and I'm afraid it doesn't support UNICODE. :-(
Too bad OE is not an option, and Mozilla has trashed my newsgroup
database once too many times. And I don't have enough disk space to
install Emacs just to get GNU.
Ok, it's not your newsreader fault, but you could always set it to use
7-bit ASCII (this is USENET, after all ...)
Robin Fairbairns
>Stefan Baums <ba...@hum.ku.dk> wrote:
>> Specifying the input encoding to Omega is trivial and does not use the
>>
>> \ocp\MyTexUTF=inutf8
>> \DefaultInputTranslation onebyte \MyTexUTF
>> \InputTranslation currentfile \MyTexUTF
>>
>> at the head of the file, and of course you can define some
>> abbreviation for this.
>
>Unfortunately it's not so easy like that, except in simple
>cases. Actually, ocp's can be used for lots of things and
>they must be properly coordinated. Furthermore, there
>are some issues in that approach, which works fine
>because ascii chars have the same representation in utf8,
>but how do you tell Omega that the current file use "windows"
>ucs2? (The problem of the hen and the egg.) Or how do
>you combine koi8 and uft8 in the same file? Problems like
>that (and many more) were discussed in the LaTeX3 list.
people in the group now called iso/iec jtc1/sc2 have been trying to
work out how to deal with this problem since way before i was involved
in standardisation, and they never came up with a solution.
the osi people came nearest with the presentation layer of the model:
a separate channel for carrying the schema knowledge for the data
being communicated. but osi died (effectively, anyway) and the
alternative skates over the problem.
it is inevitable that data represented in a variety of character sets
must have some lowest common denominator. iso 2022 (i don't know if
it's still current) used ascii escape sequences to designate codes
into the various quadrants of the 8-bit character sets it dealt with;
i can't imagine any other way of doing it. but i surely don't fancy
trying to proselytise for an omega-based macro package that requires
converts to type the sort of thing stefan baums offers.
(i wouldn't mind it, but then i write latex macros in my spare time,
so plainly don't count.)
>Omega needs many improvements, and that's what John
>and Yannis are doing.
even though it's rather difficult, at times, to detect what they
actually _have_ done.
>After that, work on developping a
>new multilingual interface fully integrated will LaTeX
>will be resumed. Part of the discussions about that
>is available on
>
> http://www.math.utah.edu:8080/pub/tex/mail/latex-l_20010301.txt
>
>Sadly, I've been unable to find a url with
>the full discussion. If someone knows one, please send it
doesn't the listserv maintain archives of the list? i thought it
did... send a message "help" to the listserv address.
>because my Outlook deleted without any warning all the
>messages from the LaTeX3 list.
it would do. there's potential for microsoft to lose money if we get
lambda right ;-)
--
Robin Fairbairns, Cambridge -- rf10 at cam dot ac dot uk
Donald Arseneau
> Giuseppe Bilotta <obl...@freemail.it> writes:
>
> > I guess his newsreader is at fault here.
>
> Hardly. My post is properly encoded as UTF‐8 ...
I thought GB was referring to my reader, which, I realized all
along, was not parsing the utf8. I just thought the result was
amusingly ironic.
But why use those characters for hyphens and apostrophes in
plain text?
Donald Arseneau as...@triumf.ca
Robin Fairbairns
>Stefan Baums <ba...@hum.ku.dk> writes:
>> Giuseppe Bilotta <obl...@freemail.it> writes:
>>
>> > I guess his newsreader is at fault here.
>>
(i've translated how it appears to me)
btw, i repudiate all those who claim that we shouldn't rely on
8-bit-clean news transport. this was a reasonable incantation in the
80s (when you couldn't even rely on ascii remaining stable if it came
through an ibm server) but the spread of technology has gone a bit
further since then.
>I thought GB was referring to my reader, which, I realized all
>along, was not parsing the utf8. I just thought the result was
>amusingly ironic.
>
>But why use those characters for hyphens and apostrophes in
>plain text?
the first is a dash, and we are all to remember that the ascii
characters we think of as quotes were originally supposed to be
diacritics not punctuation. a weird thought: ascii was intended to be
more useless than we've treated it over all those years ;-)
Apostolos Syropoulos
> As for making Omega more accessible,
> I intend to do the best I can; but help and cooperation from other interested
> users would certainly help to get it done faster.
A forthcoming title on LaTeX and Lambda which will be published by
Springer-Verlag fully documents Omega and its capabilities. Not only
OTPs and OVPs but also Omega's \SGML commands and the commands related to
writing directions. In addition, the book emphasizes multilingual typesetting
with LaTeX and or Lambda. We hope that the book will be available sometime
during August 2002.
Apostolos Syropoulos
Graham Douglas
Apostolos Syropoulos <apos...@ocean1.ee.duth.gr> wrote in message
news:8ca192d2.02041...@posting.google.com...
Hi Apostolos
Dare I ask how much that book
is likely to cost?
Regards
Graham
Apostolos Syropoulos
> > A forthcoming title on LaTeX and Lambda which will be published by
> > Springer-Verlag fully documents Omega and its capabilities. Not only
>
> Hi Apostolos
>
> Dare I ask how much that book
> is likely to cost?
Frankly, I have no idea, but I suppose it should cost around 30-40 Euro.
Apostolos Syropoulos
Rowland McDonnell
[snip]
> You may want to upgrade your newsreader to a less ancient version
> and/or configure it properly.
I'm using the most recent version of my newsreader and it's configured
properly - but it doesn't display your text as you intended it to be
displayed.
Maybe the fact that so many people see garbage when you post like that
means it might be an idea to stick with 7 bit ASCII?
Rowland.
--
Remove the animal for email address: rowland....@dog.physics.org
PGP pub key 0x62DCCA78 Sorry - the spam got to me
http://www.mag-uk.org
UK biker? Join MAG and help keep bureaucracy at bay
David Eppstein
<1faqsuh.1jd4jgshzuf3qN%real-addr...@flur.bltigibbet>,
real-addr...@flur.bltigibbet (Rowland McDonnell) wrote:
> I'm using the most recent version of my newsreader and it's configured
> properly - but it doesn't display your text as you intended it to be
> displayed.
>
> Maybe the fact that so many people see garbage when you post like that
> means it might be an idea to stick with 7 bit ASCII?
MTNW 3.2 (a Mac newsreader, different from the one Rowland's using)
displays Stefan's original post just fine (using the correct UTF-8
encoding it requests). Donald Arseneau's followup post copied the UTF-8
text but called for it to be displayed as ISO-8859-1, resulting in my
newsreader correctly displaying garbage. Perhaps there is a bug in the
Gnus/5.0807 version Arseneau posted with?
Requesting that people stick to 7-bit ASCII is not a good solution -- it
would prevent Stefan from correctly spelling the name of his university.
Using TeX-isms for the accents might be appropriate for this group but
is not pretty.
Rowland, which of these posts were you complaining about MacSoup's
display of?
--
David Eppstein UC Irvine Dept. of Information & Computer Science
epps...@ics.uci.edu http://www.ics.uci.edu/~eppstein/
Giuseppe Bilotta
> Requesting that people stick to 7-bit ASCII is not a good solution -- it
> would prevent Stefan from correctly spelling the name of his university.
> Using TeX-isms for the accents might be appropriate for this group but
> is not pretty.
Maybe he should move to some other university with a 7-bit ASCII name
;-)
Rowland McDonnell
> In article
> <1faqsuh.1jd4jgshzuf3qN%real-addr...@flur.bltigibbet>,
> real-addr...@flur.bltigibbet (Rowland McDonnell) wrote:
>
> > I'm using the most recent version of my newsreader and it's configured
> > properly - but it doesn't display your text as you intended it to be
> > displayed.
> >
> > Maybe the fact that so many people see garbage when you post like that
> > means it might be an idea to stick with 7 bit ASCII?
>
> MTNW 3.2 (a Mac newsreader, different from the one Rowland's using)
> displays Stefan's original post just fine (using the correct UTF-8
> encoding it requests).
I assume that the reason this works is that you're using MacOS X? I
can't see any sign of Unicode support on my 9.2.2 Mac.
[snip]
> Requesting that people stick to 7-bit ASCII is not a good solution -- it
> would prevent Stefan from correctly spelling the name of his university.
> Using TeX-isms for the accents might be appropriate for this group but
> is not pretty.
Good point.
> Rowland, which of these posts were you complaining about MacSoup's
> display of?
Quite a few - the one containing, for example:
[snip]
> Hardly. My post is properly encoded as UTF‐8 and displays just fine
[snip]
> What’s more, I received my hyphens and apostrophes (hardly advanced
> features of Unicode...) back ungarbled in at least David Kastrup’s
> quote from my post, see
[snip]
is a bit strange - the apostrophes come out as:
\^a\textbullet\.{} (yes, really)
which ain't exactly great.
Whatever it was that was supposed to go between UTF and 8 in the first
line of the quotation comes out as:
\^a\textbullet$\Delta$
David Eppstein
<1far28s.1u6fcmtncccttN%real-addr...@flur.bltigibbet>,
real-addr...@flur.bltigibbet (Rowland McDonnell) wrote:
> > MTNW 3.2 (a Mac newsreader, different from the one Rowland's using)
> > displays Stefan's original post just fine (using the correct UTF-8
> > encoding it requests).
>
> I assume that the reason this works is that you're using MacOS X? I
> can't see any sign of Unicode support on my 9.2.2 Mac.
MTNW 3.1 under OS 9 also displays Stefan's UTF-8 messages correctly.
Rowland McDonnell
> In article
> <1far28s.1u6fcmtncccttN%real-addr...@flur.bltigibbet>,
> real-addr...@flur.bltigibbet (Rowland McDonnell) wrote:
>
> > > MTNW 3.2 (a Mac newsreader, different from the one Rowland's using)
> > > displays Stefan's original post just fine (using the correct UTF-8
> > > encoding it requests).
> >
> > I assume that the reason this works is that you're using MacOS X? I
> > can't see any sign of Unicode support on my 9.2.2 Mac.
>
> MTNW 3.1 under OS 9 also displays Stefan's UTF-8 messages correctly.
How does it manage that? Or rather, what system components do you have
installed which allow Unicode to be used? As I say, I can't see any
sign of Unicode support in *my* 9.2.2 installation - I do recall seeing
suchlike some time ago and I also recall uninstalling it because it
caused instability, but this is all from memory.
Stefan Baums
hyphen, en-dash, and em-dash? Left and right quote? The TeX
equivalents of
‐ – — “ ”
are
- -- --- `` ''
As for moving to an ASCII compatible university, that's happening:
does "University of Washington" make you happier than "Københavns
Universtitet"? Check back in October, then...
Cheers,
Rowland McDonnell
> Surely, people on this newsgroup can appreciate distinguishing betwen
> hyphen, en-dash, and em-dash? Left and right quote? The TeX
> equivalents of
>
> ‐ �€" — “ ”
>
> are
>
> - -- --- `` ''
Or, from the point of view of my newsreader, the LaTeX equivalents are:
\^{a}\textbullet$\Delta$
\^{a}\textbullet\wassat?
\^{a}\textbullet\%
\^{a}\textbullet\dunnowhatthisiseither
\^{a}\textbullet\v{}
> As for moving to an ASCII compatible university, that's happening:
> does "University of Washington" make you happier than "Københavns
> Universtitet"? Check back in October, then...
Coo! Hope you enjoy the move :-)
Giuseppe Bilotta
> Stefan Baums <ba...@hum.ku.dk> wrote:
>
> > Surely, people on this newsgroup can appreciate distinguishing betwen
> > hyphen, en-dash, and em-dash? Left and right quote? The TeX
> > equivalents of
> >
> > ‐ �€" — “ ”
> >
> > are
> >
> > - -- --- `` ''
>
> Or, from the point of view of my newsreader, the LaTeX equivalents are:
>
> \^{a}\textbullet$\Delta$
> \^{a}\textbullet\wassat?
> \^{a}\textbullet\%
> \^{a}\textbullet\dunnowhatthisiseither
> \^{a}\textbullet\v{}
On my machine, I have \euro instead of \textbullet, \qedsymbol instead
of Delta, " instead of \wassat?, �´ instead of \%, \oe instead of
\dunnowhatthisisieither, and again \qedsymbol.
Peter Flynn
> Stefan Baums <ba...@hum.ku.dk> wrote:
>
>
>>Surely, people on this newsgroup can appreciate distinguishing betwen
>>hyphen, en-dash, and em-dash? Left and right quote? The TeX
>>equivalents of
>>
>>
>>are
>>
>> - -- --- `` ''
>
> Or, from the point of view of my newsreader, the LaTeX equivalents are:
>
> \^{a}\textbullet$\Delta$
> \^{a}\textbullet\wassat?
> \^{a}\textbullet\%
> \^{a}\textbullet\dunnowhatthisiseither
> \^{a}\textbullet\v{}
Or indeed mine, which showed me
\^{a}\texteuro?
\^{a}\texteuro"
\^{a}\texteuro"
\^{a}\texteuro\oe
\^{a}\texteuro?
We have a long way to go...
///Peter