On 17 May 2014 08:30, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote: > ... > 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. >
Probably something like http://www.ctan.org/pkg/leftidx is a good choice. >> > 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? >> One problem with breqn is that it is apparently orphan software. The original author is no longer supporting it and no one else is currently maintaining it. There are several bug reports and some comments on the web about how difficult it is to understand the coding. If we are talking about a replacement/upgrade of TexFormat then perhaps the best long term solution is to handle line folding inside TeXFormat. It would be natural to control this (e.g. line width) by setting option flags as Waldek suggests. I realize that this might involve a very substantial re-write of the package but most of the required logic is already present in the texbreak C program. > Ralf Hemmecke wrote: >> 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... > As an option in TexFormat it probably would not be too difficult to replace very long output, e.g. based simply on a maximum string length for generated raw LaTeX, with some boilerplate text telling the user that the output line length exceeds the maximum allowed. This statement could be allowed to stand in the book.dvi rather than trying to reproduce the same output that a user would see without the option set. -- 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 fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
