things that seem unfixable

[David Farmer]

A good reason to put effort toward the development of MBX is
the commitment to do things "right". This means:

-- semantic markup that can be converted to *any* common format
-- human readable and writable source files
-- not forcing everyone to handle every aspect of book production
-- and a lot more.

However, documents are complicated and output formats have limitations, so
maybe it is impossible to always do things "right"?

I have gathered 5 examples where it seems to be the case that
there is no way to avoid some type of unacceptable compromise
in the MBX source. I am interested in learning about other possible
examples. (Note that I am not referring to cases where MBX has not
yet developed a vocabulary to do what you want, such as the ongoing
discussion of Sage cells in lists. What I want are examples of
things that are broken, and either there is no good fix, or the
fix breaks something else.)

My examples are described here:

http://aimath.org/~farmer/print/shortcomings.html

For the convenience of commenting on my examples, I list their titles here:

1. Punctuation after math mode

2. Excessive markup

3. Carriage returns in a paragraph

4. Typesetting functions with a tall argument

5. Set builder notation

I have a suggestion for how to address each of those, but first I would
like to have more examples to test my proposed approach.

Regards,

David

[Alex Jordan]

Right now, the following feels unfixable to me. But I remain uncertain if this
is an item for your list. Perhaps it's more a matter of the right technology not
existing yet.  Or, existing, but unknown to this group.

You have a picture in mind (in an abstract sense, not a particular file). The
picture has text in it. For example, a simple model of a water molecule, with
words labeling the oxygen and hydrogen atoms.

How do you make it so that the overall image will be the size you want it to be
while also making the text the size you want it to be (for the sake of simplicity,
suppose this is the same size as ambient paragraph text).

What image making tool to use? Once you laboriously tweak things in your image-
making, using say width=50% on the image, can you be free to later make it
width=100% without making the text any bigger?

Or, with the image width=50%, how do you make it so that a web browser user can
change their default font size (Zoom Text Only) and have that affect the text in the
image too, but leave the image itself at 50%?

[Bob Plantz]

Alex, perhaps this at least partially answers your question. Go to http://bob.cs.sonoma.edu/MBX/sec-clogic.html and scroll down to Figures 7.1.1 and 7.1.2. Figure 7.1.1 has width=68% and 7.1.2 has width=28%. As you can see, the text is the same size even though the figure "sizes" are vastly different.

I produced these figures with the LaTeX Circuit Macros. They are "drawn" in the m4 macro language, then converted to tex tikzpicture. I then wrap the code in <latex-image-code>  <![CDATA[...]]> </latex-image-code>, xi:include the file, and run the mbx script on the source. I can provide more details.

Tweaking the width to get the right figure size has no effect on the text size.

--Bob Plantz

--
You received this message because you are subscribed to the Google Groups "MathBook XML Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mathbook-xml-support+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Farmer]

Text on images is a great example, and I have added it to the list, along
with this analysis:

MathJax matches the size of the surrounding text,
so something along these lines is already happening.

If the image is SVG, and the words are <tt>text</tt> in the SVG
(possibly with some CSS class), then the source will have enough
structure that in principle it should be possible to scale the
text separately from the image.

[Oscar Levin]

Bob,

I would like more details.  Perhaps in a different thread, not to hijack this important discussion.  I had asked about this issue last summer here: https://groups.google.com/d/msg/mathbook-xml-support/zEOOtFxmYPs/y8PrFoEGEAAJ.  Or perhaps the mbx script works differently now?

Oscar.

[Rob Beezer]

On 01/19/2017 04:53 AM, David Farmer wrote:
> Text on images is a great example

Tables in a side-by-side present a similar problem.

A side-by-side has "panels" organized horizontally. You can specify their
widths as percentages (in flexible ways) and then margins and spacing are
computed automatically, with a couple of options.

An image placed in a panel is scaled to fit the width. This will exhibit Alex's
example. But tables are worse (before and after this past summer's refactor).

The table is not scaled, so there is no coordination between the width of the
panel and the width of the table. So the panel width is a bit of a fiction, and
the table can easily run off the right side of the panel.

I did find some ways to scale a table to a specific width, but now the text of
the table will shrink/grow to appear different than the surrounding text (like
text on images). And we know for large factors, scaling fonts linearly is not
optimal.

Mea culpa.

Rob

[Bob Plantz]

OOOPS!!! (A big oops.) My mistake. I haven't been working on the book for a while so wasn't on top of what I did to create these figures. I just did some experiments and learned that changing the width also changes the text size. Turns out that I have to adjust the width to get the figures to be (nearly) uniform in size, and that coincidentally gives me a nice font size.

Regarding drawing figures, I did most of mine with the LaTeX Circuit Macros, and a few with the LaTeX picture environment. I can say more about drawing with these tools, but that should probably be outside the MBX support areas.

Very sorry for my mistake.

--(Embarrassed) Bob

To unsubscribe from this group and stop receiving emails from it, send an email to mathbook-xml-support+unsubscrib...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Rob Beezer]

Another one, much like \text{.}. For LaTeX output.

If your proof ends with display math, the tombstone is likely to be on an
additional line, with nothing but itself, flush right.

The "solution" is "\qedhere" stuffed up with the math. So something to
recognize and accomplish automatically, and not burden an author with.

Different environments, and equation numbering, complicate the matter. Some
helpful comments from Barbara Beeton:

http://tex.stackexchange.com/questions/101929/qed-or-qedhere-at-the-end-of-split-environment

I've not checked the MathJax side of this at all.

Rob

[D. Brian Walton]

Punctuation before math-mode is also an issue.

I just had an example "(<m>0 \lt x \lt 3</m>)" which broke the line immediately after the opening parenthesis. Obviously, this is the same underlying issue as having punctuation land on the line after the math, but I thought I'd point this out in case it hadn't been noticed earlier.

- Brian

[Rob Beezer]

Dear Brian,

Thanks for the report. I just pasted this (sans quote marks) into the sample
article and get no unwanted line break in LaTeX, or PDF, or rendered HTML.

Can you send more context, or even better, experiment by adding this to the
minimal article and sending that as a minimal working example?

I've not seen any problems on the front end, and would not expect them with "m".
"me" would be a different story.

Thanks,
Rob

> email to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-support%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
> --
> You received this message because you are subscribed to the Google Groups
> "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email

> to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-sup...@googlegroups.com>.

[David Farmer]

Brian is right, but you have to construct a line of the correct
length so that the "(" barely fits on the line.

The behavior is also browser dependent, so I'm not sure it is
possible to make a real example that always works for testing purposes.

I hadn't realized that can happen, nor did my script that fixes
the "punctuation after" problem have parentheses among the characters
it looks for.

David

> email to mathbook-xml-sup...@googlegroups.com.

[D. Brian Walton]

http://educ.jmu.edu/~waltondb/MMB/projection-cobweb.html

In Example 2.5.2 directly above the final figure (jsxgraph) is an inequality in parentheses that splits immediately after the open parenthesis.

Brian

     email to mathbook-xml-support+unsubscrib...@googlegroups.com

     <mailto:mathbook-xml-support%2Bunsu...@googlegroups.com>.
     For more options, visit https://groups.google.com/d/optout
     <https://groups.google.com/d/optout>.


 --
 You received this message because you are subscribed to the Google Groups
 "MathBook XML Support" group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email

 to mathbook-xml-support+unsubscrib...@googlegroups.com
 <mailto:mathbook-xml-support+unsub...@googlegroups.com>.

 For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "MathBook XML Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mathbook-xml-support+unsubscrib...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "MathBook XML Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mathbook-xml-support+unsubscrib...@googlegroups.com.

[Rob Beezer]

Thanks, David and Brian. Got it. HTML, inline math, right margin and the
punctuation gets split from the math. Typically a comma.

I'm going to work today some on "sentence ending display math" and will keep
this next case in mind as I do that.

Rob

[David Farmer]

I think this is another example, but I'd like comments before I
add it to my online list.

By default, parentheses should grow to be the proper height:
the author should not have to supply \left and \right each time.
In those cases where that behavior looks bad, then the author
can hard-code a specific size.

David

ps. I have updated the list with new examples mentioned in this
thread

http://aimath.org/~farmer/print/shortcomings.html

[Alex Jordan]

By default, parentheses should grow to be the proper height:
the author should not have to supply \left and \right each time.

Are we sure? Some level of LaTeX knowledge is assumed. We are not
planning to turn "sin(x)" into "\sin(x)", for example (or are we?) So there is a
question of where to draw that line about altering an author's LaTeX input for
their own good. You are suggesting authors do not need to use knowledge
about parentheses behavior within LaTeX math. But which side of the line is
this issue on?

Some challenges with this, for the record. If we are trying to solve this, I think
it is hard; maybe unfixable.

• Would MBX figure out the appropriate height and insert things
  like \big(, or would it defer to LaTeX and use things like \left(?
  (Rhetorical; the solution to the problem might involve one, the
  other, or both.)
• If MBX were to use \left( and \right), there is an issue involving
  parentheses that indicate grouping versus those that indicate
  function input. It has to do with horizontal spacing outside the
  parentheses. I do not swear that the example below is the only
  way to look at the issue, but try out:
  
  $$2\left(\frac{x}{2}\right)+\left(\frac{x}{2}\right)^2+f\left(\frac{x}{2}\right)+\sin\left(\frac{x}{2}\right)$$
  
  where I think the first two expressions look OK and the latter two
  do not. Compared to:
  
  $$2\mathopen{}\left(\frac{x}{2}\right)\mathclose{}+\mathopen{}\left(\frac{x}{2}\right)\mathclose{}^2+f\mathopen{}\left(\frac{x}{2}\right)\mathclose{}+\sin\mathopen{}\left(\frac{x}{2}\right)\mathclose{}$$
  
  where the latter two look OK, maybe the first one is OK, but the
  second one is not OK.
  

 

[David Farmer]

Dear Alex,

Well, you definitely have anticipated what I think is the
key point. Before I describe what I was doing, let me
clarify that I think:

a) The proper default is to insert \left and \right automatically,
with \big, \Big, \bigg, etc reserved for over-riding the automatic
re-sizing.

b) Also inserting \mathopen{}, etc, in the case of function
arguments.

c) I the case of something like f(3), where you can tell in advance
that the parentheses do not need to grow, it is not yet clear to me
whether it is better to leave it "plain", or to insert the
\mathopen{}\left etc.

d) I do not think of this as fixing errors in the author's LaTeX
(and so I would not suggest adding the backslash in "3 + sin(x)").
I see this as addressing a design flaw in TeX.

From the "shortcomings" list of unfixable problems, I have been
investigating:
Example 4): Typesetting functions with a tall argument

As you will recall, the hope is to write f(x) as \fa(f}{x},
where \fa means "function apply", and x may be something complicated.
The \fa macro inserts \mathopen and \left and whatever else
is needed to make the typesetting look good.

As you note, the key point is to determine which parentheses
contain the argument of a function, and which are for grouping.
I had claimed that this can be automated (and you expressed
skepticism!).

I have spent some time writing a script to identify, in APEX
calculus, which parentheses are for the arguments of functions and
which are not.

Of the approximately 9700 parentheses pairs in math mode, I identify
approximately 6300 as being the argument of a function, and
approximately 3200 for grouping. There are 186 pairs I fail
to categorize. Examining those, I see that I could make my
script more clever and get it below 100, but (as the source is
currently written) there are cases which probably can't be resolved
algorithmically.

So, at least at the level of a calculus textbook, 98 percent of
the time we can determine the type of parentheses. Since \left
occurs more than 1000 times in the source, there is plenty of
opportunity to clean up the source and make it easier on authors.

David

ps. I am pretty sure I know how to clean up the source to take
care of the remaining cases, and I am guessing that doing so
is easier and more natural than having to insert extra markup
by hand. But I need to experiment a bit more.

On Mon, 23 Jan 2017, Alex Jordan wrote:

>
> By default, parentheses should grow to be the proper height:
> the author should not have to supply \left and \right each time.
>
>
> Are we sure? Some level of LaTeX knowledge is assumed. We are not
> planning to turn "sin(x)" into "\sin(x)", for example (or are we?) So there is a
> question of where to draw that line about altering an author's LaTeX input for
> their own good. You are suggesting authors do not need to use knowledge
> about parentheses behavior within LaTeX math. But which side of the line is
> this issue on?
>
> Some challenges with this, for the record. If we are trying to solve this, I think
> it is hard; maybe unfixable.

> * Would MBX figure out the appropriate height and insert things

> like \big(, or would it defer to LaTeX and use things like \left(?
> (Rhetorical; the solution to the problem might involve one, the
> other, or both.)

> * If MBX were to use \left( and \right), there is an issue involving

> parentheses that indicate grouping versus those that indicate
> function input. It has to do with horizontal spacing outside the
> parentheses. I do not swear that the example below is the only
> way to look at the issue, but try out:
>
> $$2\left(\frac{x}{2}\right)+\left(\frac{x}{2}\right)^2+f\left(\frac{x}{2}\right)+\sin\left(\frac{x}
> {2}\right)$$
>
> where I think the first two expressions look OK and the latter two
> do not. Compared to:
>
> $$2\mathopen{}\left(\frac{x}{2}\right)\mathclose{}+\mathopen{}\left(\frac{x}{2}\right)\mathclose{}^
> 2+f\mathopen{}\left(\frac{x}{2}\right)\mathclose{}+\sin\mathopen{}\left(\frac{x}{2}\right)\mathclos
> e{}$$
>
> where the latter two look OK, maybe the first one is OK, but the
> second one is not OK.
>
>
>
>  
>
>
>

[Alex Jordan]

David, out of curiosity, how would you handle this one?

Distribute <m>a<m> in the expression <m>a(x+\frac{1}{2})</m> and then evaluate
the expression <m>b(x+\frac{1}{2})</m> where <m>b</m> is a function.

A different, but related question. In the ORCCA forum, Carl just asked about things
like <m>(1+(-2))</m>. Is there any hope for automating that the outer parens be bigger?

[David Farmer]

> A different, but related question. In the ORCCA forum, Carl just asked about things
> like <m>(1+(-2))</m>. Is there any hope for automating that the outer parens be bigger?

I replied on the ORCCA forum, but maybe not so clearly. That particular
case is very easy to handle. And, surprisingly to me, is yet another
example for my "unfixable" list. Maybe you already knew this, but

<m>\left(1+\left(-2\right)\right)</m>

fails to do what you want, and it fails in two ways.

1) All those parentheses will be the same (small, default) size.
So it looks like you really do need to use \big.

2) If you do this

<m>\big(1+\left(-2\right)\big)</m>

then (it looks to me) that there is extra space between the two
rightmost parentheses. So, the \right seems to do nothing in terms
of the size of the parentheses, but it does do something else,
which you don't want. So you can't just start throwing \lefts and
\rights all over the place. (Sounds like I am advocating against
violence!)

However, if you use the "directional" versions of \big, then it seems
okay:

<m>\bigl(1+\left(-2\right)\bigr)</m>


The conclusion is the same: this can definitely be automated, but once
the code parses the expression, it needs to be careful about which of
the various size directives are used. (I should also say that I
support the slight increase in size of nested parentheses, and maybe
that should be the default, but there will need to be an option to
turn it off.)

I hope there are a lot of people enjoying these detailed discussions
of parentheses!

[Rob Beezer]

On 01/25/2017 08:36 AM, David Farmer wrote:
> I hope there are a lot of people enjoying these detailed discussions
> of parentheses!

Yes! At least one lurker here enjoying the conversation, and looking forward to
the resulting improvements to LaTeX shortcomings!

[Rob Beezer]

On 01/25/2017 08:36 AM, David Farmer wrote:

> I hope there are a lot of people enjoying these detailed discussions
> of parentheses!

I'd like to point out that one of the main advantages of MBX is the production
of LaTeX that attempts to avoid many of the pitfalls of organizing document
structure, while also having a human-readable body, a conflict-free preamble,
and details that lead to the best typographic quality possible. It is not
perfect, but it keeps improving.

So I am all in favor of this discussion to discern how we can also best enhance
the actual math bits authored in LaTeX within "m", "me", "men", "md", and "mdn".
This is something I've largely ignored while concentrating on other aspects of
authoring and production.

Rob

[Joe Christensen]

Hello, 

Has this issue "(<m>math-stuff</m>)" been addressed?  While rare, I have also seen it pull the ) to the next line.

However, my related issue is:  "<m>x</m>-component" is getting split between lines with the hyphen going with the component instead of with the <m>x</m> (as you would expect).

Joe

[Rob Beezer]

Dear Joe,

No real progress on this sort of punctuation around the math-bits. In large
part, this is a fault of the browser and MathJax, in my opinion. If I saw an
easy way to alleviate the problem, I'd get more excited about it, but I think it
would be a lot of work to get right, without introducing accidental bad
side-effects.

I did make an issue so we don't lose track of it again.

https://github.com/rbeezer/mathbook/issues/697

Thanks,
Rob

> --
> You received this message because you are subscribed to the Google Groups
> "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email

> to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-sup...@googlegroups.com>.