From: David Kastrup <dak@gnu.org>
Subject: Re: LaTeX-Fill-Paragraph and inline images
Date: 09 Feb 2003 17:37:32 +0100 [thread overview]
Message-ID: <x5adh55s1f.fsf@lola.goethe.zz> (raw)
In-Reply-To: b25v7s$4rs$1@sapa.inka.de
"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
next prev parent reply other threads:[~2003-02-09 16:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-08 15:43 LaTeX-Fill-Paragraph and inline images Felix E. Klee
2003-02-09 15:53 ` Kai Großjohann
2003-02-09 16:23 ` Felix E. Klee
2003-02-09 16:37 ` David Kastrup [this message]
2003-02-09 17:44 ` Felix E. Klee
2003-02-10 20:38 ` David Kastrup
2003-02-21 15:02 ` Felix E. Klee
2003-02-21 15:50 ` David Kastrup
2003-02-21 23:02 ` Felix E. Klee
2003-02-21 23:18 ` David Kastrup
2003-02-21 23:35 ` Glenn Morris
2003-02-21 23:50 ` Stefan Monnier <foo@acm.com>
2003-02-22 9:44 ` Felix E. Klee
2003-02-22 20:53 ` Stefan Monnier
2003-02-22 21:07 ` Kai Großjohann
2003-02-23 20:20 ` Felix E. Klee
2003-02-27 9:15 ` Gernot Hassenpflug
2003-02-27 11:58 ` Felix E. Klee
2003-02-27 13:27 ` David Kastrup
2003-02-21 16:01 ` Stefan Monnier <foo@acm.com>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=x5adh55s1f.fsf@lola.goethe.zz \
--to=dak@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).