LaTeX-Fill-Paragraph and inline images

LaTeX-Fill-Paragraph and inline images

[Felix E. Klee]

Hi,

I'm using preview-latex mode together with AUC TeX mode when editing 
LaTeX documents. preview-latex can compile certain parts (eg. 
equations) of LaTeX documents and replace them by inline images. This, 
however, causes LaTeX-Fill-Paragraph to misbehave since it still breaks 
lines according to the source code. 

Take for example the following code:
  Bla bla bla bla bla bla bla bla bla bla bla $\hat{\tilde{\ddot{x}}}$
  bla bla.
After applying preview-LaTeX everything could fit on one line:
  Bla bla bla bla bla bla bla bla bla bla bla [IMG] bla bla.
But LaTeX-Fill-Paragraph would still break it as follows, because it 
doesn't know about the image:
  Bla bla bla bla bla bla bla bla bla bla bla [IMG] 
  bla bla.

Therefore, I'm looking for a LaTeX-Fill-Paragraph replacement that 
breaks lines correctly when inline images are used. Instead of 
specifying a fill column the user would specify the desired width of 
paragraphs in pixels or centimeters. This might also be interesting 
when using variable width fonts instead of fixed width fonts.

Does such a function exist? Is it feasible?

Felix

Re: LaTeX-Fill-Paragraph and inline images

[Kai Großjohann]

"Felix E. Klee" <felix.klee@inka.de> writes:

> Therefore, I'm looking for a LaTeX-Fill-Paragraph replacement that 
> breaks lines correctly when inline images are used. Instead of 
> specifying a fill column the user would specify the desired width of 
> paragraphs in pixels or centimeters. This might also be interesting 
> when using variable width fonts instead of fixed width fonts.

Does this problem come from using images, or from using overlays?  I
think it's probably the overlays, but I'm not sure.
-- 
A turnip curses Elvis

Re: LaTeX-Fill-Paragraph and inline images

[Felix E. Klee]

Kai Großjohann wrote:
>> Therefore, I'm looking for a LaTeX-Fill-Paragraph replacement that
>> breaks lines correctly when inline images are used. Instead of
>> specifying a fill column the user would specify the desired width of
>> paragraphs in pixels or centimeters. This might also be interesting
>> when using variable width fonts instead of fixed width fonts.
> 
> Does this problem come from using images, or from using overlays?  I
> think it's probably the overlays, but I'm not sure.

What are overlays? The problem occurs because LaTeX-Fill-Paragraph 
formats text according to the underlying source code, it doesn't know 
about the inline images. An formatting algorithm that might work would 
be something like this:

1. Go to the beginning of a paragraph. 
2. Remove all newlines from that paragraph
3. Set the variable LINE_WIDTH to 0.
4. Add the width of the next visible entity (single character, inline
   image, ...) to LINE_WIDTH.
5. If LINE_WIDTH > MAX_LINE_WIDTH then
     a) In the paragraph add a newline before the last entity processed.
     b) Go back one entity.
     c) Continue at step 3 unless we're finished with formatting the
        paragraph.
   else
     Continue at step 4.

Felix

Re: LaTeX-Fill-Paragraph and inline images

[David Kastrup]

"Felix E. Klee" <felix.klee@inka.de> writes:

> Kai Großjohann wrote:
> >> Therefore, I'm looking for a LaTeX-Fill-Paragraph replacement that
> >> breaks lines correctly when inline images are used. Instead of
> >> specifying a fill column the user would specify the desired width of
> >> paragraphs in pixels or centimeters. This might also be interesting
> >> when using variable width fonts instead of fixed width fonts.
> > 
> > Does this problem come from using images, or from using overlays?  I
> > think it's probably the overlays, but I'm not sure.
> 
> What are overlays? The problem occurs because LaTeX-Fill-Paragraph 
> formats text according to the underlying source code, it doesn't know 
> about the inline images. An formatting algorithm that might work would 
> be something like this:
> 
> 1. Go to the beginning of a paragraph. 
> 2. Remove all newlines from that paragraph
> 3. Set the variable LINE_WIDTH to 0.
> 4. Add the width of the next visible entity (single character, inline
>    image, ...) to LINE_WIDTH.
> 5. If LINE_WIDTH > MAX_LINE_WIDTH then
>      a) In the paragraph add a newline before the last entity processed.
>      b) Go back one entity.
>      c) Continue at step 3 unless we're finished with formatting the
>         paragraph.
>    else
>      Continue at step 4.

If things were that easy...  The intent of the formatting from AUCTeX
is to make the source more readable.  Are those images part of the
source?  Debatable.  But it may not be a good idea to break things
like text math across lines when it can be reasonably avoided, anyway.

Your "algorithm" also more or less seems to imply using "entities".
AUCTeX not only formats, it also indents.  Should it be looking
inside of "entities" for that purpose?  And so on...

Of course, the current interaction (or rather its completely absence)
of preview-latex and AUCTeX is not nice in that regard.  Would you
want to work on it?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: LaTeX-Fill-Paragraph and inline images

[Felix E. Klee]

David Kastrup wrote:
>> What are overlays? The problem occurs because LaTeX-Fill-Paragraph
>> formats text according to the underlying source code, it doesn't know
>> about the inline images. An formatting algorithm that might work
>> would be something like this:
>> 
>> 1. Go to the beginning of a paragraph.
>> 2. Remove all newlines from that paragraph
>> 3. Set the variable LINE_WIDTH to 0.
>> 4. Add the width of the next visible entity (single character, inline
>>    image, ...) to LINE_WIDTH.
>> 5. If LINE_WIDTH > MAX_LINE_WIDTH then
>>      a) In the paragraph add a newline before the last entity
>>      processed. b) Go back one entity.
>>      c) Continue at step 3 unless we're finished with formatting the
>>         paragraph.
>>    else
>>      Continue at step 4.
> 
> If things were that easy...  The intent of the formatting from AUCTeX
> is to make the source more readable.  Are those images part of theb
> source?  Debatable.  But it may not be a good idea to break things
> like text math across lines when it can be reasonably avoided, anyway.
> 
> Your "algorithm" also more or less seems to imply using "entities".
> AUCTeX not only formats, it also indents.  Should it be looking
> inside of "entities" for that purpose?  And so on...

The algorithm should not format the source of the entities. It should 
only format what is visible to the user after he has applied 
preview-latex.
 
> Of course, the current interaction (or rather its completely absence)
> of preview-latex and AUCTeX is not nice in that regard.  Would you
> want to work on it?

It would be interesting to try out the algorithm on plain text documents 
that are displayed with a variable width font. Do you know how to get 
the width in pixels of an "entity".

Felix

Re: LaTeX-Fill-Paragraph and inline images

[David Kastrup]

"Felix E. Klee" <felix.klee@inka.de> writes:

> David Kastrup wrote:
> >> What are overlays? The problem occurs because LaTeX-Fill-Paragraph
> >> formats text according to the underlying source code, it doesn't know
> >> about the inline images. An formatting algorithm that might work
> >> would be something like this:
> >> 
> >> 1. Go to the beginning of a paragraph.
> >> 2. Remove all newlines from that paragraph
> >> 3. Set the variable LINE_WIDTH to 0.
> >> 4. Add the width of the next visible entity (single character, inline
> >>    image, ...) to LINE_WIDTH.
> >> 5. If LINE_WIDTH > MAX_LINE_WIDTH then
> >>      a) In the paragraph add a newline before the last entity
> >>      processed. b) Go back one entity.
> >>      c) Continue at step 3 unless we're finished with formatting the
> >>         paragraph.
> >>    else
> >>      Continue at step 4.
> > 
> > If things were that easy...  The intent of the formatting from AUCTeX
> > is to make the source more readable.  Are those images part of the
> > source?  Debatable.  But it may not be a good idea to break things
> > like text math across lines when it can be reasonably avoided, anyway.
> > 
> > Your "algorithm" also more or less seems to imply using "entities".
> > AUCTeX not only formats, it also indents.  Should it be looking
> > inside of "entities" for that purpose?  And so on...
> 
> The algorithm should not format the source of the entities. It should 
> only format what is visible to the user after he has applied 
> preview-latex.

Why?  The purpose of AUCTeX's formatting is not to make the source
ugly when one does not use preview-latex.  One wants to have a
reasonable look of the source also in that case.

> > Of course, the current interaction (or rather its completely absence)
> > of preview-latex and AUCTeX is not nice in that regard.  Would you
> > want to work on it?
> 
> It would be interesting to try out the algorithm on plain text documents 
> that are displayed with a variable width font. Do you know how to get 
> the width in pixels of an "entity".

char-width, string-width, and more complicated commands (like
compute-motion) come to mind.  Probably quite different with XEmacs,
though.

Take a look at the respective sections in the Emacs Lisp manual.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: LaTeX-Fill-Paragraph and inline images

[Felix E. Klee]

David Kastrup wrote:
>> The algorithm should not format the source of the entities. It should
>> only format what is visible to the user after he has applied
>> preview-latex.
> 
> Why?  The purpose of AUCTeX's formatting is not to make the source
> ugly when one does not use preview-latex.  One wants to have a
> reasonable look of the source also in that case.

The problem is that code which is formatted to look pretty in source form 
doesn't neccessarily look pretty when displayed with preview-latex (e.g. 
the images created by preview-latex often are much smaller than the 
corresponding source). What I want is a tool that formats only for on 
screen viewing. Maybe it could even preserve the original format as e.g. 
the longlines mode does.
 
>> It would be interesting to try out the algorithm on plain text documents
>> that are displayed with a variable width font. Do you know how to get
>> the width in pixels of an "entity".
> 
> char-width, 

Not applicable since it returns the width of a char measured in columns, not 
in pixels.

> string-width, 

Has the same problem as char-width.

> and more complicated commands (like compute-motion) come to mind. 

Also seems to use columns for measuring distances.

> Probably quite different with XEmacs, though.

I don't use XEmacs.

> Take a look at the respective sections in the Emacs Lisp manual.

Unfortunately, I couldn't find a command that returns the width in pixels of 
a certain character in the default font. But maybe I can get that 
information via an external tool. Any ideas?

Felix

PS: Sorry for answering so late. I have overlooked your message.

Re: LaTeX-Fill-Paragraph and inline images

[David Kastrup]

"Felix E. Klee" <felix.klee@inka.de> writes:

> David Kastrup wrote:
> >> The algorithm should not format the source of the entities. It should
> >> only format what is visible to the user after he has applied
> >> preview-latex.
> > 
> > Why?  The purpose of AUCTeX's formatting is not to make the source
> > ugly when one does not use preview-latex.  One wants to have a
> > reasonable look of the source also in that case.
> 
> The problem is that code which is formatted to look pretty in source form 
> doesn't neccessarily look pretty when displayed with preview-latex (e.g. 
> the images created by preview-latex often are much smaller than the 
> corresponding source). What I want is a tool that formats only for on 
> screen viewing. Maybe it could even preserve the original format as e.g. 
> the longlines mode does.
>  
> >> It would be interesting to try out the algorithm on plain text
> >> documents that are displayed with a variable width font. Do you
> >> know how to get the width in pixels of an "entity".
> 
> > and more complicated commands (like compute-motion) come to mind. 
> 
> Also seems to use columns for measuring distances.

Well, but it takes into account fractional sizes, so it should be
workable for that purpose.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: LaTeX-Fill-Paragraph and inline images

[Stefan Monnier <foo@acm.com>]

> Unfortunately, I couldn't find a command that returns the width in pixels of
> a certain character in the default font. But maybe I can get that
> information via an external tool. Any ideas?

I believe you'll need to do some C coding in Emacs for that.
It would be great if you could help out,


        Stefan

Re: LaTeX-Fill-Paragraph and inline images

[Felix E. Klee]

David Kastrup wrote:
>> > and more complicated commands (like compute-motion) come to mind.
>> 
>> Also seems to use columns for measuring distances.
> 
> Well, but it takes into account fractional sizes, so it should be
> workable for that purpose.

Really? How can I test this? I just tried inserting an image into an 
elisp buffer (using M-x insert-file) but compute-motion only seems to 
see the source of the image. Therefore I can't get fractional sizes.

And, as mentioned before, I need a command that gives me the width of 
characters in pixels (or inches, or whatever) in order to treat 
variable width fonts properly. I already asked whether such a command 
exists (thread "Getting the width of a character?") but noone answered. 
Do you have an idea how to proceed?

Felix

Re: LaTeX-Fill-Paragraph and inline images

[David Kastrup]

"Felix E. Klee" <felix.klee@inka.de> writes:

> David Kastrup wrote:
> >> > and more complicated commands (like compute-motion) come to mind.
> >> 
> >> Also seems to use columns for measuring distances.
> > 
> > Well, but it takes into account fractional sizes, so it should be
> > workable for that purpose.
> 
> Really? How can I test this? I just tried inserting an image into an 
> elisp buffer (using M-x insert-file) but compute-motion only seems to 
> see the source of the image.

Since when does insert-file display an image?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: LaTeX-Fill-Paragraph and inline images

[Glenn Morris]

David Kastrup wrote:

> Since when does insert-file display an image?

Since whenever auto-image-file-mode was enabled.

Re: LaTeX-Fill-Paragraph and inline images

[Stefan Monnier <foo@acm.com>]

> variable width fonts properly. I already asked whether such a command
> exists (thread "Getting the width of a character?") but noone answered.

I answered, but it seems you didn't get my messages.


        Stefan

Re: LaTeX-Fill-Paragraph and inline images

[Felix E. Klee]

Stefan Monnier wrote:
>> variable width fonts properly. I already asked whether such a command
>> exists (thread "Getting the width of a character?") but noone
>> answered.
> 
> I answered, 

Could you please repost your message?

> but it seems you didn't get my messages.

It looks like your message hasn't been correctly distributed among news 
servers. I can't even find it with Google Groups.

Felix

Re: LaTeX-Fill-Paragraph and inline images

[Stefan Monnier]

> Could you please repost your message?

Here are the messages I still have on my server:
They're not in gmane either, so maybe they never left my newsserver :-(
Has anybody else seen them ?


        Stefan

================================
Date: 10 Feb 2003 11:21:01 -0500

>>> Therefore, I'm looking for a LaTeX-Fill-Paragraph replacement that
>>> breaks lines correctly when inline images are used. Instead of
>>> specifying a fill column the user would specify the desired width of
>>> paragraphs in pixels or centimeters. This might also be interesting
>>> when using variable width fonts instead of fixed width fonts.

That would be neat, but nobody has written the code to do it yet.
I don't think it can be done in elisp right now, so we first need
some C code (exported to elisp) so that you can determine pixel
positioning.

I know someone has started work on it, but help is still welcome,


        Stefan

================================
Date: 21 Feb 2003 11:01:48 -0500

> Unfortunately, I couldn't find a command that returns the width in pixels of
> a certain character in the default font. But maybe I can get that
> information via an external tool. Any ideas?

I believe you'll need to do some C coding in Emacs for that.
It would be great if you could help out,


        Stefan

Re: LaTeX-Fill-Paragraph and inline images

[Kai Großjohann]

"Stefan Monnier" <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> writes:

> Has anybody else seen them ?

I remember the second one.  I'm reading via news.cis.dfn.de.
-- 
A preposition is not a good thing to end a sentence with.

Re: LaTeX-Fill-Paragraph and inline images

[Felix E. Klee]

Stefan Monnier wrote:

>> Could you please repost your message?
> 
> Here are the messages I still have on my server:
> They're not in gmane either, so maybe they never left my newsserver
> :-( Has anybody else seen them ?

The second one is available on my newsserver, the first one is not.

>>>> Therefore, I'm looking for a LaTeX-Fill-Paragraph replacement that
>>>> breaks lines correctly when inline images are used. Instead of
>>>> specifying a fill column the user would specify the desired width
>>>> of paragraphs in pixels or centimeters. This might also be
>>>> interesting when using variable width fonts instead of fixed width
>>>> fonts.
> 
> That would be neat, but nobody has written the code to do it yet.
> I don't think it can be done in elisp right now, so we first need
> some C code (exported to elisp) so that you can determine pixel
> positioning.

Well, getting the width of a character can probably easily be done (on 
X11 based systems) by accessing the XFontStruct structure with a small 
C module. More powerful, though, would be something like compute-motion 
that works with pixels instead of lines and columns.

> I know someone has started work on it, but help is still welcome,

Maybe I'll try out that XFontStruct thing just for fun, but probably not 
too soon.

Felix

-- 
To contact me in private don't reply but send email to
  felix DOT klee AT inka DOT de

Re: LaTeX-Fill-Paragraph and inline images

[Gernot Hassenpflug]

Hello Felix,

I'm late on reading the group - and I hope this information is not
totally superfluous by now!

Reading through the RefTeX pages on sourceforge, the following link
from the main page (http://preview-latex.sourceforge.net/) might be
useful to you and the respondents in the discussion. In particular,
what is wrong with having say WhizzyTeX open a separate window and
therefore offers more clarity, while at the same time editing the
offending text segments with preview-LaTeX quick and dirty. A binding
of the LaTeX compilation could be done to run both p-L and w-T so that
updating is synchronized?

http://preview-latex.sourceforge.net/others.html

Programs & Packages Related to preview-latex

preview-latex is explicitly focused on placing identifiable previewed
scraps of TeX, compositions, right in your source buffer in the way
most convenient for editing. It does not cater for any other WYSIWYG
concepts. In particular, it does not change the manner in which you
have to enter your input: you still need to know what and how to
type. If you have had no previous exposure to LaTeX, are accustomed to
usual text processors, and do not need to work on LaTeX documents
together with other authors, then there may be more convenient ways
for you to harness the typesetting quality of LaTeX. Two TeX-related
word processors with a more `customary' user and input interface are:

    * GNU TeXmacs is a true WYSIWYG system /snip/

    * LyX is quite closer coupled to LaTeX /snip/

While both of these systems have ways of entering LaTeX code that the
processor itself does not understand, creating documents making
extensive use of this feature would be defeating their point.

Because of this and because they save their texts in their own
formats, those systems are not quite frontends to LaTeX, but rather
employ LaTeX as a backend. They provide you with convenient access to
LaTeX's quality, but not to its native flexibility, power, and
interchangeability.

So there may be good reason to bite the bullet, and use a real editor
intended for editing basically plain text, and Emacs is an excellent
contender. If you go for Emacs, here are additional packages worth
looking at:

* X-Symbol is a powerful input and display system for the vast variety
  of math characters and accented character constructs that LaTeX
  provides. It will replace those control sequences with more readable
  characters, and it will offer both new and experienced users a
  number of convenient and fast methods to enter them. While
  preview-latex focuses on providing convenience for LaTeX's output,
  X-Symbol tries this for the input.
    
* WhizzyTeX also plays in the previewing ballpark, but not in the
  source buffer of Emacs. It updates a preview window interactively
  while you are working on the source. Its preview is page-oriented in
  a separate window.
    
* AUC TeX, is the LaTeX major-mode. preview-latex will currently not
  work without it.

* RefTeX provides support for doing labels, references and citations
  in LaTeX. It is already installed in Emacs and just needs to be
  activated. See the info page.

-- 
G Hassenpflug RASC, Kyoto University

Re: LaTeX-Fill-Paragraph and inline images

[Felix E. Klee]

Gernot Hassenpflug wrote:
> Reading through the RefTeX pages on sourceforge, the following link
> from the main page (http://preview-latex.sourceforge.net/) might be
> useful to you and the respondents in the discussion. In particular,
> what is wrong with having say WhizzyTeX open a separate window and
> therefore offers more clarity, while at the same time editing the
> offending text segments with preview-LaTeX quick and dirty. A binding
> of the LaTeX compilation could be done to run both p-L and w-T so that
> updating is synchronized?

Thanks for pointing me to other tools. I have considered them as well but 
there are several arguments that let me favor Preview-LaTeX:
1. I can do all my editing in EMACS, my favorite text editor, and I don't
   have to move my head between a WhizzyTeX window and the editor window.
2. I often work on a Laptop which only has a 1024x768 sized screen and
   having an EMACS and the WhizzyTeX window open at the same time will be
   problematic. In addition the laptop probably isn't fast enough to let
   WhizzyTeX update text in real time (I haven't tried it, though).
3. As for Lyx and Texmacs: I want to have full control over the LaTeX code
   I'm writing and, in addition, I use a lot of macros and 3rd party
   packages.
4. Writing a fill-paragraph function that works properly with Preview-LaTeX
   shouldn't be too hard once we have something similar to compute-motion
   that measures in pixels.

Felix

Re: LaTeX-Fill-Paragraph and inline images

[David Kastrup]

"Felix E. Klee" <felix.klee@inka.de> writes:

> 4. Writing a fill-paragraph function that works properly with
>    Preview-LaTeX shouldn't be too hard once we have something
>    similar to compute-motion that measures in pixels.

There are two ideas that would help a lot already, but which I have
not found time to implement yet:

a) let AUCTeX honor the "hard" property on line breaks and spaces.
Make preview-latex declare all previews as "hard".  When AUCTeX can't
break a line where it wants, it will back up to the next non-hard
space or line break and break there, if there is not yet a break
present.  This would help in most cases as long as you insert
appropriate breaks in your previewed matter and start previewing
before letting AUCTeX reformat paragraphs or stuff.

b) environments, groups, mathematics, footnotes etc. introduce a structure of
nesting.  Let AUCTeX, when indenting/wrapping, make sure that new
levels of nesting are introduced on lines of themselves.  That is,
wrap \footnote{...} to a new line (ending the previous line with a
comment char if necessary) unless it completely fits on the current
line.

This way of wrapping would need no interaction with preview-latex and
would yield more readable results also when doing normal text entry.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum