Ralf Hemmecke wrote:
>
> On 05/17/2014 04:29 AM, Waldek Hebisch wrote:
>
> > More generaly,
> > I was looking at other problems with TexFormat and it seems
> > that we should have a bunch of TeX macros to supply needed
> > constructs. For example, for escaping we could use macros
> > which provide special TeX characters, but of category
> > "normal character". Some are already included in TeX, but
> > w could define missing ones.
>
> I consider that as problem that is orthogonal to my \verb stuff.
> And thus it should be a separate patch.
OK.
> Furthermore, for the book I introduced )set output latex on.
> I actually don't think, we should have both, tex and latex. I'd rather
> simply replace TeX by LaTeX. Do you think that nowadays there are still
> people who want to include pure TeX commands instead of LaTeX
> equivalents? The amsmath package has become more or less a standard.
> And the \begin{dmath} ... \end{dmath} of breqn.sty even seems to be better.
Well, keeping compatiblity with plain TeX would be nice but
if it is too much trouble, then I do not insist. I think that
extra domain for LaTeX is not a good idea. Rather, we should
allow setting options for TexFormat. Techically having a
domain like TexFormatOptions (or maybe FormatOptions) would be
more elegant, but in practice a bunch of functions in
TexFormat to set options should do.
> > In issue tracker we have
> > report about missing ALTSUPERSUB in TexFormat. With proper
> > TeX macro adding it to TexFormat would be very easy.
> > Without such macro this looks like hard problem.
>
> What do you mean?
>
> The right thing to solve this issue is to document all the operators of
> OutputForm and then (and that for all formatters, not only TeX) have an
> appropriate equivalent.
Well operators in OutputForm correspond to exported functions
and it is easy to find out relation between functions and
operators. In particular ALTSUPERSUB corresponds to 'supersub'
and we have:
supersub : (%, List %) -> %
++ supersub(a, [sub1, super1, sub2, super2, ...])
++ creates a form with each subscript aligned
++ under each superscript.
I do not know about standard TeX/LaTeX operator to get alignment.
OTOH setting first scripts as boxes and using phantoms it should
be not hard to do. Of course, there are details like keeping
track of modes and list manipulations.
> > Then there are some changes where it is not clear if we want
> > to make them. In particular, I see that you suppressed
> > output in LexTriangular example. Why? Is it problem
> > with breqn?
>
> Oh, OK, that's a workaround to make everything compile. Yes, it's a
> problem with breqn.sty. The output is simply to large and computation in
> breqn.sty leads to (I think) integer overflow if a TeX register.
>
> I've switched it off, because I think that nobody wants to read 3 pages
> of computed output. I think the problem is actually not breqn, but
> rather that the content is not really well thought of. For tutorial
> purposes, it's enough to see by which commands one computes something,
> but one can explicitly say that the output shown at that place has been
> truncated, or one even just explicitly computes output that exactly
> shows what one wants to focus on.
The author had some didactic pupropose in mind. Probably wanted
to show features of packege and it is possible that simpler
example will not do. In HyperDoc output is at first folded, and
only after clik on the button it shows up.
> So yes, you might think that this is a step back, but for me it's a
> technical thing that must be done. As I said, the actual contents of the
> book needs revision anyway and at revision time one can also deal with
> these issues of too large output.
I understand that this is right compromise for making book.
But in such case I would rather make a separate (hopefully
small) patch with workarounds and say that for making book
this extra patch is needed. .dvi and .pdf are portable so
we can distribute book made from patched sources and for
most of users that will be all what they want. There is
inconvenience for folks who want to re-make book, but
if we commit workarounds there is tendency to forget
about them...
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.