Re: [AUCTeX-devel] preview-latex, dvipng, and LyX
Jan-Åke Larsson <[EMAIL PROTECTED]> writes: >>>The latter would actually be useful for preview-latex as well, only >>>that it would be nice to direct the output completely elsewhere >>>(Emacs does not capture stderr separately): I often have to run >>>preview-latex several times when new fonts get generated, because >>>the font generating output confuses it. > > That pattern would get rid of this problem as well: IIRC the output > of the mktexpk script is always a closed "[1] [14] ..." in which > case the "\[([0-9]+) " part would only match BOP because of the > trailing space and the "height=(-?[0-9]+)" would match EOP. Uh, just forget I mentioned preview-latex in that context: we don't parse the output of dvipng. The problem is with parsing the output of LaTeX, not of dvipng. So for now just LyX is the problem. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: [AUCTeX-devel] preview-latex, dvipng, and LyX
Enrico Forestieri <[EMAIL PROTECTED]> writes:
> sorry if this is not the right list. In this case, please, redirect me
> to the right one.
The list is quite correct, though there might be a dvipng-specific
list, too.
> As you know, LyX (http://www.lyx.org) uses both the preview-latex
> package and dvipng to display snippet previews of LaTeX math
> formulas. In order to do so it also relies on the output (stdout) of
> dvipng to capture the snippet number and its height and depth.
>
> However, in recent versions of preview-latex and dvipng the output
> devised for LyX's sake gets corrupted in the following way:
>
> $ dvipng ...
> This is dvipng 1.7 Copyright 2002-2005 Jan-Ake Larsson
> [1 (preview-latex version 11.81) depth=6 height=16]
>
> this output confuses the script LyX uses for generating preview
> snippets, which, instead, is expecting an output like this:
A lesson is learnt, but the damage is irreversible.
I mean, dvipng and preview.sty have been released in this manner, so
there is no sane around letting LyX detect this string and deal with
it. That's the only way to minimize the impact, even if dvipng get
changed again in the next version to give this information in a
different way. So I am copying the LyX developer list with this mail:
they will have to be a part of damage control.
> $ dvipng ...
> This is dvipng 1.7 Copyright 2002-2005 Jan-Ake Larsson
> [1 depth=6 height=16]
>
> I found that the problem is due to both recent versions of preview-latex
> and dvipng. For example, this problem doesn't show up in debian testing
> but manifests itself on Windows with MikTeX (where a more recent version
> of preview.sty is installed).
>
> Here is the relevant part of the diff between the versions of preview.sty
> in debian tetex and in MikTeX:
>
> $ diff -u preview.sty.tetex preview.sty.miktex
> ...
> @@ -83,6 +85,7 @@
> \DeclareOption{dvips}{%
>[EMAIL PROTECTED]@ne
>[EMAIL PROTECTED]
> + \special{!/[EMAIL PROTECTED]([EMAIL PROTECTED])def}
>\special{!userdict begin/preview-bop-level 0 def%
>/bop-hook{/preview-bop-level dup load dup 0 le{/isls false def%
>/vsize 792 def/hsize 612 def}if 1 add store}bind def%
> ...
>
>
> and here is the relevant code in the dvipng (version 1.7) special.c source
> file causing the problem:
>
>
> if (strncmp(buffer,"!/[EMAIL PROTECTED](",18)==0) {
> buffer+=18;
> length-=18;
> while (length>0 && buffer[length]!=')')
> length--;
> if (page_imagep==NULL)
> Message(BE_NONQUIET," (preview-latex version %.*s)",length,buffer);
> return;
> }
>
> /* preview-latex' tightpage option */
> if (strncmp(buffer,"!/[EMAIL PROTECTED]",19)==0) {
> buffer+=19;
> SKIPSPACES(buffer);
> if (strncmp(buffer,"true",4)==0) {
> if (page_imagep==NULL)
> Message(BE_NONQUIET," (preview-latex tightpage option detected,\
> will use its bounding box)");
> flags |= PREVIEW_LATEX_TIGHTPAGE;
> return;
> }
> }
> if (strncmp(buffer,"!userdict",9)==0
> && strstr(buffer+10,"7{currentfile token not{stop}if 65781.76
> div")!=NULL)
> {
> if (page_imagep==NULL && ~flags & PREVIEW_LATEX_TIGHTPAGE)
> Message(BE_NONQUIET," (preview-latex <= 0.9.1 tightpage option
> detected,\
> will use its bounding box)");
> flags |= PREVIEW_LATEX_TIGHTPAGE;
> return;
> }
>
>
> As a solution, it would suffice to replace BE_NONQUIET with
> BE_VERBOSE in the code snippet above, such as to not clutter stdout
> between "[1 " and "depth=...]".
>
> I would like to ask if this acceptable for you, or, in case it is not,
> if you can suggest an alternative. In this regard, what it is important
> is that nothing goes inside "[" ... "]" except snippet number and depth
> and height information.
>
> A second problem that I noticed is that when a font is missing and
> mktexpk (or alike) gets called to generate it, its stdout gets intermixed
> with that of dvipng, causing a similar (but worse) confusion.
>
> Is it possible to have the stdout of those helper programs redirected to
> stderr?
The latter would actually be useful for preview-latex as well, only
that it would be nice to direct the output completely elsewhere (Emacs
does not capture stderr separately): I often have to run preview-latex
several times when new fonts get generated, because the font
generating output confuses it.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: Unexpected popularity for preview-latex
Nirmal Govind <[EMAIL PROTECTED]> writes: > I just downloaded preview-latex.. it seems to require xemacs or some > sort of emacs with image support.. do I really need to install > xemacs if I only intend to use it with LyX? Does preview-latex > depend on emacs to do what it does? preview-latex does (it is the name of the Emacs package providing the previews), but preview.sty and its support files don't. In a nutshell, if you have the preview-latex tarball, as a LyX user you will only need the files in the `latex' subdirectory. The autoconf-based installation will probably barf without Emacs, so you need to install the files according to the latex/README-preview file by hand. On CTAN:macros/latex/contrib/supported/preview we also have a standalone LaTeX distribution (CTAN is the comprehensive TeX archive network, more info at, say, www.dante.de). With RedHat preview-latex-common should do the trick as a package, with Debian we have preview-latex-styles or something like that. I am currently thinking about what name to use for a standalone LaTeX distribution on preview-latex's development site so that people don't download it unless they really need it (and they won't need it if they already downloaded the preview-latex tarball itself). I could also offer to add uploading the tarball for the standalone LaTeX styles to some LyX-related server, if you would prefer that. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Unexpected popularity for preview-latex
In the last few days, the Sourceforge statistics for preview-latex exhibited quite large page views, particularly considering that we are in a time of relative quietness (ok, the last release managed over a 1000 hits, about double the current interest, but still...). It's pretty obvious where this current popularity comes from: LyX-1.3.0 has been released, and the announcement contain a link to our home page (preview.sty is used in the new math preview functionality). The announcement appeared with various delays on various lists/sites/groups, and there have been corresponding highs of web traffic. Kudos, and thanks for the exposure, folks! I guess I should get thinking about how to make it easier to download just the LaTeX style files: after all, I already provide CTAN with such an archive. Problem is that the archive file name on CTAN is probably not the best choice for Sourceforge: it does nothing to suggest that you don't need to fetch it in case you are going to use the complete preview-latex package under Emacs. On CTAN, that is not a problem, since the archive for just the preview styles is in a completely different directory. Perhaps have the file keep the same contents, but call it something different like preview-only-styles-0.7.9.tar.gz (we already have some only-docs which is also optional). That's not a name I would want for CTAN, though... Thoughts? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: jura.cls mit LyX
John Levon <[EMAIL PROTECTED]> writes:
> On Wed, Dec 11, 2002 at 10:13:33AM +0100, David Kastrup wrote:
>
> > be appreciated by people. Or even a manual way which asks the user a
> > lot of questions. Or some interactive tool which you call and which
> > let's you browse/change a layout with a menu-like structure. You
>
> Actually I've wanted such for a while. The idea that this could be
> semi-automated is intriguing, though I must admit I don't understand.
Well, stupid example: let's say the user has some document exercising
all the sectioning structures in his documents. We can then do
something like
\makeatletter
\let\@savestartsection\@startsection
\renewcommand\@startsection[6]{\toks@{{#1}{#2}{#3}{#4}{#5}{#6}}
\errmessage{Sectioncall: \the\toks@}\@savestartsection}
\makeatother
And every section command when called will tell the name under which
it was called (the error message gives the error context, which will
give the responsible command) and all its arguments. If any of those
are counters or whatever (don't know the 6 arguments' meaning by
heart), one can output their definitions and \thecountername and so
on as well.
Then one would have to parse the log file for those special error
messages or other diagnostics.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: jura.cls mit LyX
Andre Poenitz <[EMAIL PROTECTED]> writes:
> On Tue, Dec 10, 2002 at 11:27:50PM +0100, David Kastrup wrote:
> > The following message is a courtesy copy of an article
> > that has been posted to de.comp.text.tex as well.
>
> I'll try to translate this (freely) into English lest we get examples of
> Norwegian or Hebrew poetry next time (comments in [] are mine)
ARGH! Please excuse my stupidity, I am switching so often between
English and German that this was completely unconscious. Of _course_
I know that lyx-devel is English spoken, it just did not occur to me
that I was no writing in English at that time. No disrespect for the
international participants was intended.
Ok, I'll try clarifying where my thoughts were as muddled in the
German not to survive the translation.
Problem was that the OP asked how complicated it would be to write a
layout file for some class with non-standard structuring commands
(jura.cls).
> Stupid question: What about trying to write a [LaTeX/TeX] package that
> writes out a LyX .layout file.
[preview-latex gets along with "foreign" classes usually]
> Then it occured to me that preview-latex is only able to do that because
> \@startsection and similar are called with suitable parameters and
> \thesection etc. are defined. LyX could hook into it
Ok, here is where my German already has been bad. preview.sty of
course is pretty much unsuited except as an inspiration. In this
case, I meant, LyX could by virtue of a special style, say
lyxlayout.sty, hook into the appropriate section generating hooks and
then notice all calls of sections and record them. Ok, this is
somewhat half-baked: layout.sty would also need to know just _what_
command happened to call it. So it would appear that layout.sty
alone would not be able to do the work. It could, however, just
issue fake error messages which would then enable an external script
to see which lines contained the sectionion commands, and the
external script could then fill in this missing information.
> and would obtain a lot of information on [Verzeichnisebenen?], math
> environments, counters etc.
>
> In the extreme case one could simply use
> "\nonstopmode\AtBeginDocument{\RequirePackage{lyxlayout}}\input{doc.tex}"
> on unknown [LaTeX] documents and end up with a basic LyX .layout.
Well, as I said, postprocessing with a script parsing the log file
would probably also be necessary.
> Idea or nonsens? I'll send a copy to lyx-devel.
Well, as language, missing things like the above detail (I know
propose a script for) and other stuff suggest, this was a late at
night addition.
Anyhow, perhaps _some_ automated way of generating layout files would
be appreciated by people. Or even a manual way which asks the user a
lot of questions. Or some interactive tool which you call and which
let's you browse/change a layout with a menu-like structure. You
might scoff at that idea and say that real men should have no problem
copying an existing file and modifying from there, but face it: that
sort of "real men" is not the target audience for LyX. LyX people
are _glad_ they have a frontend to the structured text represented by
a LaTeX file, and they would probably appreciate having one to layout
files as well.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Re: jura.cls mit LyX
The following message is a courtesy copy of an article
that has been posted to de.comp.text.tex as well.
Herbert Voss <[EMAIL PROTECTED]> writes:
> Ralf Zosel schrieb:
> >>
> >>wenn man diese Level kennt, ist es eine Kleinigkeit,
> >>sie auf ein LyX Layout zu übertragen.
> > Wenn das so einfach ist: Hast Du noch einen Tipp? Das wäre fein!
>
> sieh dir die dtk.layout oder tugboat.layout an,
> die müssten bei LyX 1.2 schon dabei sein, die
> habe ich "auf die Schnelle gestrickt" ...
Blöde Frage mal: wie wäre es denn, wenn jemand mal versucht, eine
Package zu schreiben, die so ein LyX layout rausschreibt? Ich wollte
jetzt erst einmal einen dummen Kommentar abladen, daß preview-latex
die Struktur etc problemlos erkennt, auch wenn es die Klasse gar nicht
kennt und Rhabarber Rhabarber und habe mir das natürlich zuerst
zensiert. Dann ist mir aber eingefallen, daß preview-latex das ja nur
deswegen kann, weil ja dementsprechend \@startsection oder Konsorten
mit passenden Argumenten aufgerufen werden, und \thesection und
ähnliches Gesockse ja alles definiert sind. Da könnte man sich ja im
Falle eines LyX-Laufes auch in alle Hooks hängen und hätte dann am
Ende jede Menge Info über Verzeichnisebenen, Matheumgebungen,
Zählerformen etc. zusammen.
Im Extremfall würde man einfach LyX bei unbekannter Dokumentenklasse
automatisch einmal mit
"\nonstopmode\AtBeginDocument{\RequirePackage{lyxlayout}}\input{doc.tex}"
über das Dokument drüberbrettern lassen und hätte dann zumindest
ein Grundtemplate schon beisammen, wenn man das in passender Form
rausschreibt.
Idee oder Unsinn? Ich schicke mal eine Kopie nach [EMAIL PROTECTED]
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
de.comp.text.tex FAQ: http://www.dante.de/faq/de-tex-faq>
preview-latex 0.7.4 has been released
It has also been uploaded to CTAN and should in due time be made available there. At the current point of time, it will probably just be available from SourceForge, but that should change soon. Particularly noteworthy for LyX developers: The preview.dtx style has been updated to include an option "counters". This option will issue diagnostics at the start and end of previews that output the settings of all current counters (or rather those that changed since the last diagnostic). The intention is to make it possible to keep things like equation numbers reasonably correct on updates. The usefulness of this option is probably greater where a document is processed in its entirety rather than when LyX pushes single previews through preview.sty, since in the latter case passages affecting counters are left out. The Debian package for preview-latex (here still based on 0.7.3) has recently been split into a preview-latex and a preview-latex-styles package. LyX users will need only the latter package for their preview functionality. With RedHat Linux, installing the preview-latex-common package will achieve the same, although it also installs info files and general documentation that is needed only for the operation with Emacs or XEmacs. A separate RPM containing only the style files has not been made up to now, since demand for it has not been voiced, and since it is not entirely clear what naming/dependency scheme would be best to keep things reasonably simply also for Emacs users and which would avoid unnecessary downloads of packages that users find out later conflict with others. The following are the RELEASE notes which I send here unedited, even though probably mostly the download locations will be of interest for LyX users. I apologize for the inconvenience. If you think this a problem, please contact me by mail so that a different arrangement might be made. Thanks, Release notes for version 0.7.4 of the preview-latex package: preview-latex dresses up your LaTeX source by placing judiciously selected chunks (such as single formulas) chopped from unwieldy preview pages right into its Emacs/XEmacs buffer, while keeping the original source readily accessible. You get to have your eye candy and edit it, too. The employed style file preview.sty is independently useful for extraction of selected text elements as images. The package is released under the GNU Public License (GPL). At the current point of time, at least GNU Emacs-21.1 under the X window system, AUC TeX (11.11 recommended, see below), a working LaTeX installation and GhostScript are required. This version also supports XEmacs-21, best in version 21.4.9 or later. The various Windows ports of XEmacs should work out of the box. Recent CVS versions of Windows GNU Emacs could conceivably be made to work, too, but the jury is still out on that one. Release 0.7.4 is a consolidation release containing mostly bug fixes. Several interoperatibility problems under Windows and with various GhostScript versions have been dealt with. The previous release lead to problems when buffers without associated file name were put into LaTeX-mode. If this occured while first loading preview-latex, compatibility macros caused further problems with XEmacs. As a promotional measure, preview-at-point has been added to the tool bar. The README file provides adequate information for firing up preinstalled distributions, and pointers how to provide feedback. The INSTALL file contains a special section with advice for package providers. The home page is http://preview-latex.sourceforge.net>, the SourceForge project page that among others offers anonymous CVS access is located at http://sourceforge.net/projects/preview-latex>. If you can spare the time, you can also comment on or rate this project at http://freshmeat.net/projects/preview-latex>. Additional files can be found at http://prdownloads.sourceforge.net/preview-latex>: * If you don't have texinfo 4.0 or later installed, prebuilt documentation files can be found there. * AUC TeX can be found at several places, but if you want the latest 11.11 (alpha, but stable AFAIK) with no known issues concerning preview-latex, you can find it there as well. * RPMs for preview-latex and AUC TeX are provided for users of RedHat Linux. For the binary RPMs, you will need the preview-latex-common RPM as well as the Emacs-flavor specific RPM. The RPMs require a few packages that should be readily available in current distributions. RedHat 7.3 contains Emacs-21.2 and GhostScript-6.52 which are about the minimum versions to be recommended. Later releases should work fine. XEmacs in current distributions will still be affected with a serious display bug, see the PROBLEMS file or the respective manual section. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Future preview interaction. Was: Draft paper about WYSIWYG/LaTeX
Andre Poenitz <[EMAIL PROTECTED]> writes: > On Tue, Aug 13, 2002 at 11:34:38AM +0200, David Kastrup wrote: > > Just for a try, I replaced "times" in the font selection scheme > > with "fixed". I now get a display with an array of wildly > > inconsistent font sizes. > > Maybe you don't have 'fixed' in the 'consistent' sizes for all > shapes and your 'fixed' font is not scalable? > > I am getting tired (again) of your whining. I am not even willing to > have a look whether there are real problems anymore... Ok, I won't "whine" to the LyX developer list anymore. Since I am not a user of LyX, I have no personal interest in reporting any perceived problems to the list. In case of any problems with interaction with those components of preview-latex that are used in LyX, I would ask the respective developers to direct mail to either my personal Email address, or the respective developer list [EMAIL PROTECTED] since I am not going to read the LyX developer list any more. Where only interaction with the LaTeX style file is of interest, my personal Email address will at the current point of time be more appropriate since I am the only person with TeX experience working on preview-latex. All the best, -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Draft paper about WYSIWYG/LaTeX for TUG2002
Andre Poenitz <[EMAIL PROTECTED]> writes:
> On Tue, Aug 13, 2002 at 11:32:41AM +0200, David Kastrup wrote:
> > > For "ordinary characters" like 'a', \mathbb{R}, \sum etc, either the X
> > > symbol font or suitable LaTeX fonts can be used. So saying "math fonts are
> > > ... basically being sloppily rendered line drawings" is a bit
> > > strong.
> >
> > LaTeX fonts? How?
>
> Automatically if your X server is set up to use them.
>
> Don't know what one uses with an installed version of LyX. I always
> run it from the build dir and put /path/to/lyxbuild/lib/xfonts in
> the font path.
Then perhaps the RPM for RedHat should take care to do something like
that.
> > > So why don't you use them in LyX?
> >
> > Because the menu basically just offers entering an X font name? It is
> > always a bear to dig through with xfontsel and try to find something
> > to match properly for every single font in use. That should be left
> > as a final configuration option for the experts.
>
> Come on. You are complaining that you can't use Emacs 20xsomething screen
> font but are unable to locate it with xfontsel?
No, I am complaining that getting a consistent font scheme with fonts
designed for screen use (with a matching size set, and appropriate
fonts for italic, slanted, bold and the like) would be the work of a
day at least. Certainly doable if I were interested in using LyX on
a permanent base, but certainly quite above the head of the user base
LyX tries to appeal to.
> > Note that even the programmer's editor and overall hacker tool
> > Emacs offers font selection schemes, where selecting a scheme will
> > get you a matching set of fonts. And if I naively just select the
> > default font in my X defaults, Emacs will select a fitting set of
> > italics, bold, large and so on from an appropriate scheme to match
> > it.
>
> LyX is not intended as a replacement for your favourite OS. You
> will have to use external tools from time to time I am afraid.
So what external tool would you recommend for selecting an
appropriate font set for screen use with LyX? Where have you
documented its use for that purpose?
> Fine. Now that you've learned it, it should not too hard for you to
> fix the documentation and submit it for inclusion in LyX.
Always nice to hear suggestions like that from somebody who has
explicitly stated that he would certainly never be willing to
contribute even to those components of preview-latex that will be used
within LyX.
Just as a reminder: I am reviewing LyX, not using it. I don't see why
I should be prohibited from reviewing it unless I am going to fix all
its perceived faults myself.
If you don't want to hear criticism, that's ok with me. I thought
that it would be courteous to give you feedback about my findings,
but apparently I have been mistaken.
Sorry for that,
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: Draft paper about WYSIWYG/LaTeX for TUG2002
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > >>>>> "David" == David Kastrup <[EMAIL PROTECTED]> writes: > > David> Just for a try, I replaced "times" in the font selection scheme > David> with "fixed". I now get a display with an array of wildly > David> inconsistent font sizes. > > Do you have 'use scalable fonts' unchecked? This is better if you want > to have nice unscaled bitmap fonts for times. Yes, have it unchecked. If I check it I get fonts that could not impress game consoles from ten years ago. Which is what I would have expected, and I certainly don't fault LyX for offering an option to at least try this. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Draft paper about WYSIWYG/LaTeX for TUG2002
Andre Poenitz <[EMAIL PROTECTED]> writes:
> On Mon, Aug 12, 2002 at 09:16:51PM +0200, David Kastrup wrote:
> > The default fonts on my system look like junk. Sorry, that's how it
> > is. In particular, the math fonts plainly are awful (basically being
> > sloppily rendered line drawings).
>
> This is _only_ for delimiters and accents.
>
> For "ordinary characters" like 'a', \mathbb{R}, \sum etc, either the X
> symbol font or suitable LaTeX fonts can be used. So saying "math fonts are
> ... basically being sloppily rendered line drawings" is a bit strong.
>
> > But the text fonts also are not good. Some sort of printer fonts (what
> > is it, Times or what?)
>
> It is whatever you have chosen. What do you think Edit->Preferences->
> ScreenFonts (incidently the very first tab when opening the preferences
> menu) is good for?
>
> > My Emacs source text buffers use 20x10 fixed fonts. That are fonts that
> > are actually designed for readability _at_ _screen_ _resolution_.
>
> So why don't you use them in LyX?
Just for a try, I replaced "times" in the font selection scheme with
"fixed". I now get a display with an array of wildly inconsistent
font sizes.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: Draft paper about WYSIWYG/LaTeX for TUG2002
Andre Poenitz <[EMAIL PROTECTED]> writes:
> On Mon, Aug 12, 2002 at 09:16:51PM +0200, David Kastrup wrote:
> > The default fonts on my system look like junk. Sorry, that's how it
> > is. In particular, the math fonts plainly are awful (basically being
> > sloppily rendered line drawings).
>
> This is _only_ for delimiters and accents.
>
> For "ordinary characters" like 'a', \mathbb{R}, \sum etc, either the X
> symbol font or suitable LaTeX fonts can be used. So saying "math fonts are
> ... basically being sloppily rendered line drawings" is a bit
> strong.
LaTeX fonts? How?
>
> > But the text fonts also are not good. Some sort of printer fonts (what
> > is it, Times or what?)
>
> It is whatever you have chosen. What do you think Edit->Preferences->
> ScreenFonts (incidently the very first tab when opening the preferences
> menu) is good for?
>
> > My Emacs source text buffers use 20x10 fixed fonts. That are fonts that
> > are actually designed for readability _at_ _screen_ _resolution_.
>
> So why don't you use them in LyX?
Because the menu basically just offers entering an X font name? It is
always a bear to dig through with xfontsel and try to find something
to match properly for every single font in use. That should be left
as a final configuration option for the experts.
Note that even the programmer's editor and overall hacker tool Emacs
offers font selection schemes, where selecting a scheme will get you a
matching set of fonts. And if I naively just select the default font
in my X defaults, Emacs will select a fitting set of italics, bold,
large and so on from an appropriate scheme to match it.
LyX trumpets user friendliness. There is no point in keeping people
from having to learn a few mnemonic LaTeX commands, and then demand
digging into the X font system only to arrive at a configuration that
should either be the default, or easily configurable with clicking
_few_ buttons.
BTW, the "Customization" section does not deal with how to avoid
constant justification on line ends, and the menus don't offer
anything in that line, either.
This is all LyX-1.2.0.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: Draft paper about WYSIWYG/LaTeX for TUG2002
Allan Rae <[EMAIL PROTECTED]> writes: > Figure 7 shows the editing experience for the various systems maths > editors -- except it sems for preview-latex. I can't see a cursor in > that screen shot. Shouldn't that show the actual editing experience > with the raw latex maths? "Detail view" is the phrase, and when the preview is opened for editing, there is not much preview to be seen. > Actually, I'd rather you showed both the preview and the editing > much as is shown for Whizzy-TeX (even though that would almost be > repeating Figure 6). Yes, figure 6 is supposed to show the various states a preview can be in. Figure 7 shows a typical _single_ editing situation. When you use WhizzyTeX, _both_ windows are active at once and are part of the editing situation. With preview-latex, it is either open or closed. One could only ponder whether one would try to make a screen shot with one open and a different closed preview. > The description of TeXmacs and LyX left me thinking LyX was newer > than TeXmacs when the opposite is true. Not really a problem just > an impression. Hm. Where does the impression arise? Actually, I would not even know which of the two was younger. > Otherwise I like it. Actually, it _is_ amazing and nice how many different approaches are already flying around. You get a lot of choice (and in case of Emacs, if you are unsatiable you can use all of the presented tools for it at once). -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Draft paper about WYSIWYG/LaTeX for TUG2002
Dekel Tsur <[EMAIL PROTECTED]> writes: > On Mon, Aug 12, 2002 at 07:12:35PM +0200, David Kastrup wrote: > > > > Available at > > http://preview-latex.sourceforge.net/wysiwyg-draft.pdf>. Now > > the deadline for the proceedings is already over, but this will > > certainly not be the last time I try to hand something in, and the > > talk itself is yet to happen. > > > > Comments? > > Perhaps you should mention Texlite. I decided against it since I am basically presenting different WYSIWYG paradigms, and TeXlite falls into the same category as WhizzyTeX: instant update. It is not available freely except on request to the author, and I have heard it reported as being rather unstable. So I decided to not miss much if I omit it. All of the other presented programs and systems are readily and freely available to the reader of the article. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Draft paper about WYSIWYG/LaTeX for TUG2002
John Levon <[EMAIL PROTECTED]> writes: > On Mon, Aug 12, 2002 at 07:12:35PM +0200, David Kastrup wrote: > > > > > Comments? > > another thing: I believe Angus has implemented preview mode for \input Right. I'll try to keep that in mind during the talk. It provides a (somewhat artificial) way of previewing arbitrary constructs by placing them in a separate file. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Draft paper about WYSIWYG/LaTeX for TUG2002
Dekel Tsur <[EMAIL PROTECTED]> writes: > On Mon, Aug 12, 2002 at 07:12:35PM +0200, David Kastrup wrote: > > > > Available at > > http://preview-latex.sourceforge.net/wysiwyg-draft.pdf>. Now > > the deadline for the proceedings is already over, but this will > > certainly not be the last time I try to hand something in, and the > > talk itself is yet to happen. > > > > Comments? > > Perhaps you should mention Texlite. > > "It must be noted that LyX screen display in particular in the math > area does not seem to be optimized for readability." > > What does this mean ? The default fonts on my system look like junk. Sorry, that's how it is. In particular, the math fonts plainly are awful (basically being sloppily rendered line drawings). But the text fonts also are not good. Some sort of printer fonts (what is it, Times or what?) rendered at screen resolution without antialiasing does not cut it for readability. Even with antialiasing, printer fonts at 100dpi would not be too ergonomic (substituting a washed-out display of well-rendered characters for a crisp display of badly rendered characters), but at least more tolerable (take a look at TeXmacs screenshots). My Emacs source text buffers use 20x10 fixed fonts. That are fonts that are actually designed for readability _at_ _screen_ _resolution_. This criterion need not imply fixed fonts; it just happens that I find the particular one I use more readable than the available proportional fonts here. > "LyX has the same update-per-keystroke policy that, in connection > with justification, leads to the concertina effect of shrinking > and expanding lines during normal text insertion." > > LyX can be configured to show the text on screen with ragged right > alignment, without an impact on the latex output. Good. I'll find out how, now that I am told. Will the casual user find this out easily? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Draft paper about WYSIWYG/LaTeX for TUG2002
Available at http://preview-latex.sourceforge.net/wysiwyg-draft.pdf>. Now the deadline for the proceedings is already over, but this will certainly not be the last time I try to hand something in, and the talk itself is yet to happen. Comments? Another question: suppose I want to get a demonstrable versions of some pre-1.3.0 CVS, any chance at getting at a binary for RedHat-7.3? What libraries? Probably already answered elsewhere. If so, where? Thanks. BTW, I think I'll get my last code changes into preview-latex today, and hopefully be able to release 0.7.3 tomorrow after a grace period. Sorry for the delay. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Dutch math panel typo "grieks"
Vinay <[EMAIL PROTECTED]> writes:
> Hi,
>
> in the math panel of the Dutch version of LyX 1.2.0, the button for
> the Greek characters says "gamma rho iota epsylon kappa sigma". I
> suppose it's derived from the English "gamma rho epsylon epsylon
> kappa", which is written properly, but in Dutch, it is wrong.
> The g of greek is soft and can be written as gamma, but in Dutch,
> the g of grieks is hard. There is no English equivalent, it's kind
> of a growling sound and should be written with chi. That is the
> Greek character which looks like an X.
> The sigma that is written at the end of grieks, should be the
> other sigma. It sounds exactly the same as the sigma you placed
> there, but in Greek, a sigma placed at the end of a word, should
> be written with the other sigma. This one can hardly ever be found
> in a mathematical equation, but it is in the menu under the
> button, just to the right of the sigma you used.
>
> I did not mean to be highbrow or so, but if you put so much work in
> making this nice package, you just want it to be right and I hope this
> can help you.
This "greek" or "grieks" in Greek letters is an analphabetism,
anyway. I would recommend replacing it altogether with
alpha beta gamma
which would be a better indication of Greek letters, or at least with
gamma rho alpha phi alpha iota ("letters" in old Greek).
The following will produce this:
\documentclass{minimal}
\usepackage[greek]{babel}
\usepackage{color}
\begin{document}
\fcolorbox[gray]{0.2}{0.7}{grafa'i}
\end{document}
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: caching BufferView (again)
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> >>>>> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> Andre> On Thu, Aug 01, 2002 at 02:29:16PM +0200, Jean-Marc Lasgouttes
> Andre> wrote: While we are at it: Can anybody explain me the
> Andre> advantages of multiple buffer views vs multiple LyX processes?
> >>
> Andre> Which kind of convienence would that buy us?
> >> Cut and paste between different views
>
> Andre> This would be possible if we had a flawless lyx->tex->lyx round
> Andre> trip which is important for a few other things too.
>
> I do not think this is ever going to happen. There is some information
> which is _not_ written in .tex, like for example whether a float is
> open or collapsed.
That would be the easiest exercise:
\begin{figure}
%LyX: collapse figure
[...]
Just define a nice syntax for LyX metacomments.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: caching BufferView (again)
Angus Leeming <[EMAIL PROTECTED]> writes: > On Thursday 01 August 2002 1:26 pm, Andre Poenitz wrote: > > I don't know emacs. What's C-x 2 and C-x 5 doing? > > C-x 2. Split the current window horizontally into two separate work > areas. It appears you have become alien to either Emacs or the horizon. Ok, Since I can provide this info very easily: C-x 2 runs the command split-window-vertically which is an interactive compiled Lisp function in `window'. It is bound to C-x 2, . (split-window-vertically &optional ARG) Split current window into two windows, one above the other. The uppermost window gets ARG lines and the other gets the rest. Negative arg means select the size of the lowermost window instead. With no argument, split equally or close to it. Both windows display the same buffer now current. If the variable `split-window-keep-point' is non-nil, both new windows will get the same value of point as the current window. This is often more convenient for editing. Otherwise, we chose window starts so as to minimize the amount of redisplay; this is convenient on slow terminals. The new selected window is the one that the current value of point appears in. The value of point can change if the text around point is hidden by the new mode line. [back] > C-x 5. Create a new window. (Emacs calls separate X windows "frames"): Global Bindings Starting With C-x 5: key binding --- --- C-x 5 o other-frame C-x 5 0 delete-frame C-x 5 1 delete-other-frames C-x 5 2 make-frame-command C-x 5 . find-tag-other-frame C-x 5 d dired-other-frame C-x 5 r find-file-read-only-other-frame C-x 5 C-f find-file-other-frame C-x 5 f find-file-other-frame C-x 5 b switch-to-buffer-other-frame C-x 5 m compose-mail-other-frame [back] C-x 5 2 runs the command make-frame-command which is an interactive compiled Lisp function in `frame'. It is bound to C-x 5 2, . (make-frame-command) Make a new frame, and select it if the terminal displays only one frame. [back] > > [I don't even use multiple buffers in vim.] > > No, I find it easier to use several consoles with vi too. But then again I'm > a vidiot. What's your coefficient of viscosity? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: 2 bugs and a proposal
Angus Leeming <[EMAIL PROTECTED]> writes: > > > Questions: > > > 1. Does it make sense to preview anything other than Input? > > > > Uh, yes. But this very much depends on the document in question. > > See a few examples on the <http://preview-latex.sourceforge.net> homepage. > > Other obvious candidates are figures, tables, includegraphics (you'll > > tell me that LyX already previews them in its own way, but does that > > include psfrag replacements?), picture environments, pspicture, > > psmatrix and so on. Of course, with nested such things, just take > > the outer one. > > This was actually a LyX specific question. We have an inset that wraps > LaTeX's include, verbatiminput and input commands. I was using an input > command here. Does it make sense to generate previews for the others too? > Probably not is my guess. \include starts a new page/document section. No sense in previewing a complete chapter or its equivalent. \verbatiminput is much too boring to preview (unless you get sick of LyX' screen fonts which could be prettier). \input _might_ for example contain an xfig mixed LaTeX/EPS file. > ps. It's great candy! Thanks! Sorry I did not manage to release preview-latex last week. We are doing our best to make it this week. At the current level of resonance, it will probably take a few releases in succession until all of the platforms for which no alpha testers have volunteered get it right. I doubt this will concern the LaTeX style, however. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: 2 bugs and a proposal
Angus Leeming <[EMAIL PROTECTED]> writes: > Lars Gullik Bjønnes wrote: > > > | 3. Would people like a Preview of such Input? > > > > sure. > > Oh my god! It works! See attached! This is all a secret plot from envious Emacs users that want LyX development to stall by incurring a lethal eye candy dependency on core developers. > The InsetInclude::PreviewImpl and InsetFormula::PreviewImpl are very > similar so I'll try and factor the common code into a base class. > > Questions: > 1. Does it make sense to preview anything other than Input? Uh, yes. But this very much depends on the document in question. See a few examples on the <http://preview-latex.sourceforge.net> homepage. Other obvious candidates are figures, tables, includegraphics (you'll tell me that LyX already previews them in its own way, but does that include psfrag replacements?), picture environments, pspicture, psmatrix and so on. Of course, with nested such things, just take the outer one. Since this is actually a Pandora's box, preview.sty offers a few default settings for extractions, and an elaborate LaTeX-based scheme that lets the user specify the components to be extracted to LaTeX either in the document preamble or in separate configuration files. Emacs itself has no clue about what previews the LaTeX run might turn up and where, but with the "auctex" option set, each of the preview snippets causes an error message to be generated at the start and end of it, and those error messages provide the needed correlation between exact buffer positions of the snippet and the produced image files. > 2. clearly not everything can or should be previewed, so I'll add a > bool preview; > parameter to InsetInclude::Params that defaults to false. We'll need a > button on the Include dialog to set it, so I refer you to q.1 again. > > 3. Things work only if I specify an absolute path name. Why? > Any ideas about what I should be doing to tell LaTeX where to find > the included file? Probably nothing different from what the normal processing of \input would be getting? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: New CVS version of preview.sty (one for Angus)
Angus Leeming <[EMAIL PROTECTED]> writes:
> On Monday 29 July 2002 1:22 am, David Kastrup wrote:
> > Sorry, we are still in the 0.7.3 cleanup and redocumentation cycle and
> > have not yet reached release maturity. In the course of that, I have
> > tried figuring out what goes wrong with things like seminar.sty.
> > Well, they set \mag. Ugh.
> >
> > This is now fixed: the tightpage option now takes DVI magnification
> > into account.
> >
> > At the start of document, an additional line
> > Preview: Magnification 1000
> > or similar gets output to the log.
>
> I've got the latest cvs. There is no Magnification line output for
> an article document.
Right. I issue that diagnostic only if the magnification is any
different from 1000.
> I'll try a seminar document later.
That should show it (something like 2074 or so).
> Presumably this will now change:
>
> David> Preview: Tightpage -32890 -32890 32890 32890
> David> Preview: Snippet 1 492688 0 744653
>
> David> If I call the tp numbers tp1, tp2, tp3, tp4, and the snippet values
> David> ht, dp, wd, then we have, strictly speaking,
>
> David> ascent = max(0,ht,-dp)+tp4
> David> descent = max(0,-ht,dp)-tp2
>
> ?
This is all exactly identical. Only after you finally are finished,
multiply by any specified magnification divided by 1000.
And you probably want to do the same for the fontsize when using it
for getting well-proportioned math insets.
BTW, prosper is a bit of a nuisance: it changes the default font size
_after_ \begin{document} in case you are using any style like
contemporain, so the size adjustment does not work. But I don't know
whether LyX currently caters for prosper, anyway.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
New CVS version of preview.sty (one for Angus)
Sorry, we are still in the 0.7.3 cleanup and redocumentation cycle and have not yet reached release maturity. In the course of that, I have tried figuring out what goes wrong with things like seminar.sty. Well, they set \mag. Ugh. This is now fixed: the tightpage option now takes DVI magnification into account. At the start of document, an additional line Preview: Magnification 1000 or similar gets output to the log. The borders that the tightpage option uses are, like all box dimensions, subject to the magnification factor. Since they are intended to compensate for overshooting characters, and since the overshoot is scaled along with the characters, this makes sense. Some more cosmetic changes have been done to the showlabels stuff. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: mathed: underbrace missing
Angus Leeming <[EMAIL PROTECTED]> writes: > On Wednesday 24 July 2002 1:55 pm, Axel Heinrici wrote: > > Hello > > > > I am using lyx to write my physics diploma thesis. I am very > > convinced to use lyx instead of native latex. Especially I like > > mathed. But in physics underbraces are very common. And these are > > not availible in mathed. > > I think many physicists would like this feature. > > Perhaps you should upgrade your version of LyX? underbrace is most > definitely available on LyX 1.2.x. See the attached screenshot. I'd > assume therefore that it exists on the released LyX 1.2... Even if they were not explicitly implemented in LyX could you easily access them as a special TeX sequence. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: bug in preview.sty
Angus Leeming <[EMAIL PROTECTED]> writes:
> On Wednesday 24 July 2002 9:39 am, Herbert Voss wrote:
> > this seems to be a bug in preview.sty.
> > the relevant latex code is
> >
> > \begin{eqnarray}
> > y & = & d\label{eq:2}\\
> > y & = & cx+d\\
> > y & = & bx^{2}+cx+d\\
> > y & = & ax^{3}+bx^{2}+cx+d\label{eq:5}
> > \end{eqnarray}
>
> Try upgrading to the cvs version (attached). I believe that it fixes many
> such bugs...
Not that one (see separate post for explanation). Takers? Note that
we are converging quickly towards release, so things that are
considered crucially important should be treated soon.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: bug in preview.sty
Herbert Voss <[EMAIL PROTECTED]> writes:
> this seems to be a bug in preview.sty.
> the relevant latex code is
>
> \begin{eqnarray}
> y & = & d\label{eq:2}\\
> y & = & cx+d\\
> y & = & bx^{2}+cx+d\\
> y & = & ax^{3}+bx^{2}+cx+d\label{eq:5}
> \end{eqnarray}
It's not a bug, it is a feature (of course, of course, yeah sure,
everything you say, boo, hiss). Ok, here is the gist: \label can be
used in a host of different circumstances (figures, tables,
equations...). preview.sty just stacks the labels it finds in a
preview and places them at the bottom right of the preview.
In this case, the stacking corresponds too perfectly visually with
the actual equations. I'll make the labels smaller in the next
release; at least they will not line up as perfectly as they do now.
AMSLaTeX has a different way of placing equation labels. If you use
AMSLaTeX's math environments (which are infinitely preferable to the
basic LaTeX ones), the labels will be arranged corresponding to the
actual equations instead of the overall preview box.
Personally, I am not too much of a fan of the showlabels option, and
this particular problem (which only occurs when not using the AMSLaTeX
environments) is not going to get the necessary time and attention
before getting the next release out. If anybody wants to try his
hands at it, the code in the standard package "showkeys" might or
might not give pointers about how to find out the labels. Note that
this package does not work with preview.sty since it does not impact
bounding boxes, and so the material it produces gets cut off.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: LyX catches signals, but doesn't remove lyx_tmpdir.
"R. Lahaye" <[EMAIL PROTECTED]> writes:
> From http://www.gnu.org/manual -> glibc -> Signal Handling:
>
> --
> Termination Signals
>
> [...]
>
> int SIGTERM
> The SIGTERM signal is a generic signal used to cause program
> termination. Unlike SIGKILL, this signal can be blocked,
> handled, and ignored. It is the normal way to politely ask a
> program to terminate.
>
> The shell command kill generates SIGTERM by default.
>
> int SIGINT
> The SIGINT ("program interrupt") signal is sent when the user
> types the INTR character (normally C-c). See ,
> for information about terminal driver support for C-c.
>
> [...]
>
> This, according to glibc, can give us a hint as to what signals
> are safe to be handled by dialog and which signals should be dealt
> with in a more rigorous way.
Not quite: you can type the SIGINT character only on a tty, not on a
graphics window, so it does not make sense to make a dialog on a
graphics window. You _could_ do a dialog on the actual tty where the
program has been started (and most likely the SIGINT been generated),
but in the case of a program that does not do any I/O there by
default, this would probably be more cause of confusion than anything
else.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: LyX catches signals, but doesn't remove lyx_tmpdir.
John Levon <[EMAIL PROTECTED]> writes: > On Mon, Jul 22, 2002 at 07:50:03PM +0200, Lars Gullik Bjønnes wrote: > > > This is were we disagree. > > > > IMSNHO SIGTERM and SIGINT should behave exactly the same. > > Please provide a rationale Well, SIGINT is fundamentally a tty signal. You raise it by typing the interrupt character to the console/tty on which you have started LyX explicitly. This tty is not necessarily in any way related to the XServer and/or screen on which LyX has placed its windows. If LyX fails to visibly react to the interrupt signal (and a popup on the X server is not necessarily visible to the console where the interrupt character has been typed), people have no possibility of gracefully quitting LyX from where they started it (if they have job control, they might use C-z, and then killall or something, but that's not the same thing). -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview...
Angus Leeming <[EMAIL PROTECTED]> writes: > On Monday 22 July 2002 2:39 pm, David Kastrup wrote: > > Possibly an oversight. Does the following help (apart from > > invalidating the checksum from preview.dtx)? I should probably also > > switch to a typewriter font. > > Nope. Attached is the latex file used to generate the snippets > together with the offending log file. Works here with the CVS version of preview.dtx. Which is, of course, not older than an hour or so... Perhaps one should also choose a smaller font size for the labels? \footnotesize? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview...
Angus Leeming <[EMAIL PROTECTED]> writes:
> On Monday 22 July 2002 2:19 pm, David Kastrup wrote:
> > \label works with \csname. \csname accepts character tokens. This
> > includes &$_^{} characters (unless they have been made active and
> > redefined). It is quite a bad idea to be using those characters for
> > labels, but not necessary illegal. Such labels usually work fine, so
> > the showlabels options should not make them fail when other uses
> > don't. I believe that the CVS version of preview.sty should work with
> > labels like that (for some months now). If you would check whether
> > scary-eqns.lyx comes out correct with that, I would be grateful.
>
> Now that is interesting. I've been using the cvs version of preview.sty and
> find that scary-eqns.lyx does NOT come out correctly until I disable the
> showlabels option.
Possibly an oversight. Does the following help (apart from
invalidating the checksum from preview.dtx)? I should probably also
switch to a typewriter font.
*** preview.dtx.~1.59.~ Tue Jul 16 00:47:19 2002
--- preview.dtx Mon Jul 22 15:36:00 2002
***
*** 1264,1270
%existing stuff.
%\begin{macrocode}
% \global\setbox\pr@labelbox\vbox{\unvbox\pr@labelbox
! % \hbox{\framebox{#1}}}\fi\fi\fi\fi}
%\end{macrocode}
% \end{macro}
% \begin{macro}{\pr@maketag}
--- 1264,1270
%existing stuff.
%\begin{macrocode}
% \global\setbox\pr@labelbox\vbox{\unvbox\pr@labelbox
! % \hbox{\framebox{\pr@lastlabel}}}\fi\fi\fi\fi}
%\end{macrocode}
% \end{macro}
% \begin{macro}{\pr@maketag}
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: preview...
Angus Leeming <[EMAIL PROTECTED]> writes:
> On Monday 22 July 2002 2:19 pm, David Kastrup wrote:
> > \label works with \csname. \csname accepts character tokens.
> > This includes &$_^{} characters (unless they have been made active
> > and redefined). It is quite a bad idea to be using those
> > characters for labels, but not necessary illegal. Such labels
> > usually work fine, so the showlabels options should not make them
> > fail when other uses don't. I believe that the CVS version of
> > preview.sty should work with labels like that (for some months
> > now). If you would check whether scary-eqns.lyx comes out correct
> > with that, I would be grateful.
>
> Now that is interesting. I've been using the cvs version of
> preview.sty and find that scary-eqns.lyx does NOT come out correctly
> until I disable the showlabels option.
Rats. I'll check again.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: preview...
Herbert Voss <[EMAIL PROTECTED]> writes:
> Angus Leeming wrote:
>
> > On Friday 19 July 2002 2:36 pm, Herbert Voss wrote:
> >
> >>Angus Leeming wrote:
> >>
> >>>On Friday 19 July 2002 2:19 pm, Andre Poenitz wrote:
> >>>
> >>>>.. fails with labels containing underscores. Just try the
> >>>>'scary-eqns.lyx' that came over this list recently.
> >>>>
> >>this is _no_ bug of preview.sty, it is not allowed to have
> >>TeX-command-characters in labels. preview.sty is so kind to
> >>change such characters into \?
> >>
> > The new version does something like that I believe.
>
>
> I know, but this is not a good idea of David. The users
> should know that there are some characters which they
> should be aware of. When it works for labels they wonder
> why it does not works in another case ...
\label works with \csname. \csname accepts character tokens. This
includes &$_^{} characters (unless they have been made active and
redefined). It is quite a bad idea to be using those characters for
labels, but not necessary illegal. Such labels usually work fine, so
the showlabels options should not make them fail when other uses
don't. I believe that the CVS version of preview.sty should work with
labels like that (for some months now). If you would check whether
scary-eqns.lyx comes out correct with that, I would be grateful.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: previews, display mode and vertical spacing
Angus Leeming <[EMAIL PROTECTED]> writes:
> David, we've been having a discussion about vertical space and previews. To
> fill you in and save you from trawling needlessly through the list, here's a
> synopsis.
>
> Attached are two small screenshots, one of the LyX screen wih
> previews turned on and one of the corresponding xdvi view.
>
> Note the extra vertical space inserted in the dvi file between the
> equation in display mode and the next line of text.
>
> I tried to get the preview to behave in a similar manner to the dvi
> output by modifying each snippet of math in display mode so:
>
> \begin{preview}
> \abovedisplayskip 12pt plus 3pt minus 9pt
> \[ some-snippet \]
> \belowdisplayskip 12pt plus 3pt minus 9pt
> \end{preview}
>
> To my surprise, this has no effect at all. preview.sty just ignores
> the spacing.
Yes. preview.sty extracts the material that is previewed.
Adding/arranging appropriate line spacing remains the task of the
respective editor. Since the material that preview.sty extracts is
not originally intended to be typeset as a separate entity but is
placed by LaTeX's typesetting algorithms as if it appeared mid-page,
it usually is extracted with excessive and inconsistent spacing around
it. preview.sty takes some pains to strip everything off that might
be spurious.
> My alternative suggestion to extend the descent value by an
> arbitrary amount was vetoed. The concensus (on the LyX list of
> course!) was that this really should be handled by preview.sty.
>
> Why isn't this just "automatic". Do you plan to add this to
> preview.sty?
preview.sty goes to some lengths in order to remove the spacing that
for quite a few applications interferes with previews integrating
nicely into the general text layout/line spacing. It would not be as
much a matter of "addition" to preview.sty, but removal of existing
functionality. Since TeX's algorithms distribute the spacing with
the intention of making the text appear correct in the view of a
(non-existing) environment on the page, it would not give good
results if those were left in.
For example, depending on the line length of preceding lines, TeX
either adds \abovedisplayshortskip or \abovedisplayskip. It does not
make sense to reproduce this difference when the line above is not
part of the preview.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: previews, display mode and vertical spacing
Angus Leeming <[EMAIL PROTECTED]> writes: > On Friday 19 July 2002 1:32 pm, Herbert Voss wrote: > > Angus Leeming wrote: > > > Attached are two small screenshots, one of the LyX screen wih > > > previews turned on and one of the corresponding xdvi view. > > > > > > Note the extra vertical space inserted in the dvi file between the > > > equation in display mode and the next line of text. > > > > this depends to your values of \abovedisplayskip and > > \belowdisplayskip No. > You mean that these spaces are not part of the TeX bounding box > around the equation? Is that right? (Remember that I use the same > latex preamble for both views so the values of \abovedisplayskip and > \belowdisplayskip are the same for each.) Both skips are removed by preview.sty. preview.sty tries to get just a bounding box for the actual material. It kills indentations, it kills spacings above and below material. Since preview.sty does not know whether some material will be tentatively horizontal or vertical, it has to typeset everything in a vbox, then see whether it can shrink it. Inline text material needs to get shrunk down to the basic size. Things like section headings would incldue vace spaces above and below if those skips were not removed. So you have to view the material preview.sty delivers as naked. If you know it to be a displayed equation, you might want to add the appropriate spacings for offsetting them yourself. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: bug in mathed
Dekel Tsur <[EMAIL PROTECTED]> writes:
> On Wed, Jul 17, 2002 at 06:41:57PM +0200, Andre Poenitz wrote:
> > On Wed, Jul 17, 2002 at 06:34:32PM +0200, Herbert Voss wrote:
> > > - insert->math->amsalign
> > > - cursor into the box
> > > - edit-math->add column
> > > -> align environment -> switches to alignat
> > >it should be still align!
> >
> > Does align handle more than 2 columns?
>
> Yes, but you have to read the 1st row in order to know the number of columns:
>
> \begin{align}
> 1 & 2 & 3 & 4 \\
> ...
> \end{align}
No, it does not matter which row contains the maximum number of columns.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: tie break
Herbert Voss <[EMAIL PROTECTED]> writes: > Angus Leeming wrote: > > >>? I find this more readable as I do not have to scroll down to learn that > >>str is no further modified and it might save a copy as well. > >> > > Go ahead. > > Angus > > > > > when developpers have no real new ideas or tired of > bughunting, then they beautify the code ... And it often is high time for it... -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: One for André
Juergen Vigna <[EMAIL PROTECTED]> writes: > Andre Poenitz wrote: > >>You need also some space between enclosing text and inset. I normally > >>add 2 pixels at each side to the width (see InsetText and/or > >>InsetTabular). > > As LaTeX does not add such space when changing into math mode I'd > > rather > > don't do it on screen either. > > Well you'll need that space otherwise it may be that you don't see the > cursor blinking . [Anecdotal User Interface Babble: preview-latex under Emacs also has to cater for cursor display, and Emacs defaults to blinking block cursors. First iterations of preview-latex had the entire graphic flashing when the cursor was on it. This was amended by making a transparent border of few pixels around the graphics which is all that is flashing or highlighted now. The real estate from this transparent border is taken from the preview itself by painting the transparency color before anything gets typeset, so the transparent frame gets interrupted where parts of characters actually reach into the border. The results are quite tolerable, in spite of the occasional double use of the border. The XEmacs version does not have the possibility for transparent frames, but it also does not need it: the cursor can't actually sit on a preview under XEmacs. > InsetText and InsetTabular may have some border lines and if you > don't have that added pixels the cursor will be exactly on the line > and so you're not able to see it. Can't you overlay it? > But if you don't care to see the cursor then you're free to not use > the added space (anyway you also use this in mathed for more or less > the same reasons, only that you may not remember it because it was > already that way before you started the rewrite ;) Actually, it might be that putting the cursor on the preview will open the preview and yo'll get the math editor, anyway. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: One for André
Andre Poenitz <[EMAIL PROTECTED]> writes: > On Wed, Jul 17, 2002 at 08:45:42AM +0200, Juergen Vigna wrote: > > You need also some space between enclosing text and inset. I normally > > add 2 pixels at each side to the width (see InsetText and/or > > InsetTabular). > > As LaTeX does not add such space when changing into math mode I'd rather > don't do it on screen either. preview.sty already adds 0.5bp on each side of the graphics when it generates those graphics (in order not to clip off anything protruding sligthly from the TeX bounding box). If you wanted more margin than that, you can easily tell preview.sty by changing the macro \PreviewBbAdjust (see the docs for preview.sty). When adding additional space, it makes more sense if TeX is able to draw in those pixels in the rare cases where it has something hanging out of its box rather than have it blank. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: LyX Qt2 on native win32 screenshot
Andre Poenitz <[EMAIL PROTECTED]> writes: > On Tue, Jul 16, 2002 at 07:06:07PM +0200, David Kastrup wrote: > > Strictly speaking, you are on shaky ground here in case that LyX > > comes with any third-party GPLed licenced software. In that case, > > the copyright holders of those software may insist that their stuff > > be not combined and redistributed in one binary with Qt(Windows) or > > xforms or whatever else. > > I think it would be absolutely no problem if there were no > Qt-Windows-binaries available on lyx.org. Not for you. This would only concern potential LyX-Qt-Windows-binary redistributors. > And we certainly can't prevent *cough* people from distributing > precompiled binaries in other places. So it is possible for us to > stay on the safe side. Yes. > > I can't really tell about Qt, but xforms sucks, IMO, in its general > > behavior. I think GTK LyX would be a large improvement, and an > > obviously legally unproblematic candidate for binary redistribution. > > Nobody seems to be actively working on a GTK port as far as I can > see... Oops. What sort of toolkits are in consideration, then? xforms and Qt, obviously. Anything else? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: LyX Qt2 on native win32 screenshot
John Levon <[EMAIL PROTECTED]> writes: > On Tue, Jul 16, 2002 at 02:26:01PM +0200, Moritz Moeller-Herrmann wrote: > > > But I don't think you are allowed to distribute binaries of your > > QT-Windows lyx. QT(Windows) is not GPL compatible. > > We can extend our xforms exception to Qt too possibly. Strictly speaking, you are on shaky ground here in case that LyX comes with any third-party GPLed licenced software. In that case, the copyright holders of those software may insist that their stuff be not combined and redistributed in one binary with Qt(Windows) or xforms or whatever else. Whether this would hold in court is a different matter. > Btw, Matthias Ettrich made a vague offer of a free development > license for Qt/Windows for an aspiring hacker. It might be worth > contacting him so we're not stuck on Qt 2.3 forever I can't really tell about Qt, but xforms sucks, IMO, in its general behavior. I think GTK LyX would be a large improvement, and an obviously legally unproblematic candidate for binary redistribution. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Is this the right preview info for LyX?
Angus Leeming <[EMAIL PROTECTED]> writes: > I installed the cvs version of preview.sty et al. without any problems. > Running latex on a "snippet" file and then grepping the resultant log file > shows: > > aleem@pneumon:tmp-> grep review 1lyxpreview.log > **1lyxpreview.tex > (1lyxpreview.tex > ))) (/usr/local/teTeX/share/texmf/tex/latex/preview-latex/preview.sty > Package: preview 2002/07/15 preview-latex CVS-1.59 > (/usr/local/teTeX/share/texmf/tex/latex/preview-latex/prtightpage.def > \PreviewBorder=\dimen106 > ) (/usr/local/teTeX/share/texmf/tex/latex/preview-latex/prlyx.def) > (/usr/local/ > teTeX/share/texmf/tex/latex/preview-latex/prshowlabels.def > No file 1lyxpreview.aux. > Preview: Fontsize 10pt > Preview: Tightpage -32890 -32890 32890 32890 > Preview: Snippet 1 492688 0 744653 > Preview: Snippet 2 1441792 163840 16026923 > Preview: Snippet 3 282168 0 377591 > Preview: Snippet 4 1619363 449545 16026923 > Output written on 1lyxpreview.dvi (4 pages, 1744 bytes). > > So, I'd say that all is fine. > > I don't follow your Tightpage description and certainly haven't used > it to date. The snippet info outputs the exact dimensions of the TeX box. The tightpage option adds additional side bearings to that in order to arrive at the PostScript page size so as not to cut off anything that might slightly protrude out of the TeX box. So the total size of the graphics is larger by those side bearings, and the ascent ratio is also slightly influenced by it. Probably not more than very few pixels at most, if at all. If I call the tp numbers tp1, tp2, tp3, tp4, and the snippet values ht, dp, wd, then we have, strictly speaking, ascent = max(0,ht,-dp)+tp4 descent = max(0,-ht,dp)-tp2 The tightpage dimensions can be modified by the user; in that case, before the next snippet, the changed values will be printed out in a new Tightpage line (the separate prlyx.def that you have had in your hands before printed out the tightpage info itself, and just once at the start of the document. Which should not make a difference, as I don't think anybody ever fiddled with those settings, least of all in mid-document). > ps, If you're planning on releasing preview-latex 0.73 in the next > week or so, then that 's great. It will quite probably not be possible this week, but certainly the next one. We have some documentation issues to sort out, and I have some other stuff (like native XEmacs/Windows support instead of Cygwin) that we want to have basically tested. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Is this the right preview info for LyX?
Angus Leeming <[EMAIL PROTECTED]> writes: > On Sunday 14 July 2002 1:13 am, David Kastrup wrote: > > Could you adjust your local copy of prlyx.def (and, more importantly, > > the scripts that evaluate its output) so that it will not finish the lines > > with a period? > > > I'll probably commit to CVS tomorrow, have to do a bit of testing > > before. > > When you do so, could you post the new copy here. It's better to > have /exactly/ the same file to work with when developing a parser > for it. Yes, it would. Unfortunately, it is not that easy. > I'll probably add prlyx.def to the LyX repository until you formally > release the next version of preview.sty. Thereafter I'll strike it > off again. The problem is that the output that is now generated by your copy of prlyx.def is in the new preview.dtx version generated both by a changed tightpage option as well as the lyx option. So you would need to distribute also a changed tightpage option. Unless you are not really looking at the Tightpage info, because you either disregard it in ascender/image size calculations, or you just take its default values of 0.5 PostScript points as additional borders in the image beyond those specified by the TeX dimensions into account. Ugly. I'll try to get the next release out this week to cut off the need for separate distribution. It would be nice if you told me whether the stuff generated from the current CVS version (you can just unpack it as described in README.preview, ignoring the autoconf/configure/Makefile stuff) does the trick for you before I release it. Thanks, -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: LyX Qt2 on native win32 screenshot
"Ruurd Reitsma" <[EMAIL PROTECTED]> writes: > > > It means that Trolltech believes that programmers who forget to supply a > > > name for their program (?) are mostly inclined to write programs called > > > 'freeware'. > > > > What a strange assumption. > > > > So how does one supply a name then? > > > It turns out that supplying a name wich contains 'Qt' gets rid of > 'freeware'. So I guess I'm stuck with 'QtLyX' Charming. How is GUI independence progressing? Any hope for, say, gdk under Windows? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Is this the right preview info for LyX?
Angus Leeming <[EMAIL PROTECTED]> writes: > On Friday 12 July 2002 9:13 am, David Kastrup wrote: > > David Kastrup <[EMAIL PROTECTED]> writes: > > > If that's ok, just use grep, which will probably be faster. > > > > > > grep '^Preview: Snippet /' > > > > And do the obvious correction to the line above. Argh. > > ;-) > aleem@pneumon:tmp-> grep '^Preview: Snippet' 1lyxpreview.log > Preview: Snippet 1 492688 0 744653) > Preview: Snippet 2 1441792 163840 16026923) > Preview: Snippet 3 282168 0 377591) > Preview: Snippet 4 1619363 449545 16026923) > > Could you further modify prlyx.cfg to not output that final > ')'. Attached. Could you adjust your local copy of prlyx.def (and, more importantly, the scripts that evaluate its output) so that it will not finish the Preview: Tightpage and Preview: Fontsize lines with a period? I have decided to strike them off for consistency with the Preview: Snippet line (which goes without such a period). The finally released version will also differ in that it does not mind the order of lyx/tightpage option, and that it will output a Preview: Tightpage line before any snippet whenever the user has chosen to redefine the tightpage border adjustments compared to the preceding snippet. I'll probably commit to CVS tomorrow, have to do a bit of testing before. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Is this the right preview info for LyX?
Angus Leeming <[EMAIL PROTECTED]> writes:
> On Friday 12 July 2002 10:01 am, David Kastrup wrote:
> > When we are through with this, is it ok with you if I
> > place prlyx.def into the preview distribution?
>
> That would be excellent. I'd much rather tell the LyX community to go get a
> file than have to supply it myself.
>
> > It will in a later iteration also gather color support (or rather, the
> > color support will generally included into preview.sty), but the
> > current implementation should work fine then still, I suppose.
>
> You mean invoke preview.sty with something like
>
> \usepackage[active,delayed,DVIDEV,tightpage,lyx,fg="00",bg="ffeedd"]{preview}
>
> where DVIDEV=dvips or dvipng?
Or pdftex, which can hardly be called a "DVIDEV", however. I suppose,
however, that dvipng will probably be used just with the dvips option
and just interpret the same specials. This is because it may
eventually have to look at PostScript specials and decide whether to
leave their implementation to dvips or render the stuff itself.
> We could remove the PostScript special stuff from LyX and it would
> just "do the right thing"?. That would be a noble goal indeed.
It will eventually be done, and you'll be able to retire the hacks.
But probably not before the release of LyX 1.3.0.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: Preview: request for testers
Angus Leeming <[EMAIL PROTECTED]> writes: > On Friday 12 July 2002 9:41 am, David Kastrup wrote: > > > David, I work on LyX for fun. > > > > I did not particularly address you. Hmmm, what was the reason I > > was working on LyX (if you would call it that)? > > I remember in your introduction you mentioned that you'd like people > to pay you for your LaTeX services... ? Sure thing, I am suffocating in all the money sent to me from LyX users, and you are right to scald me for all the greed I have been subjecting you to. I am currently living off savings and working on TeX stuff so that I may eventually be able to continue working on it and just sustain myself (more would be too optimistic). Instead of just looking now for a well-paying job, for which I have offers. There is no sane reason, except that I like working on TeX better than on automotive driver assistence systems. So you work on LyX for fun for fun. Your future does not depend on the future of LyX. I work on TeX for fun for earnest. If you think that this entitles you to call my motivation for working with you on LyX greed, there is little that I can say in reply. Shrug. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Preview: request for testers
Angus Leeming <[EMAIL PROTECTED]> writes: > On Friday 12 July 2002 9:41 am, David Kastrup wrote: > > Well, PNG image support will mean previews will be much more fun, and > > their loading will not spend an infinite amount of time... > > Incidentally, whilst total loading time will remain high, actual > impact on the user will be negligible once I finish this "smart > loader" stuff. The previews in PPM format will take a fraction of a > second longer to appear than the ideal case of native PNG loading > once they've been generated. "Once they've been generated". Writing dozens of MBs of data is even slower than reading them. And of course, the buffer cache gets polluted with image data instead of keeping more important stuff. Anyway, GhostScript takes up quite a bit of time, too. So while you are fiddling around with the loader, don't make decisions that would make it awkward to eventually run GhostScript in daemon mode, telling it what image it should be converting next. In preview-latex, by far the slowest stage is GhostScript, and yet it is the one least impacting responsiveness, because it can cater to the requests in the needed order, depending on what is currently on-screen. dvipng offers similar functionality. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Is this the right preview info for LyX?
Angus Leeming <[EMAIL PROTECTED]> writes: > On Friday 12 July 2002 9:13 am, David Kastrup wrote: > > David Kastrup <[EMAIL PROTECTED]> writes: > > > If that's ok, just use grep, which will probably be faster. > > > > > > grep '^Preview: Snippet /' > > > > And do the obvious correction to the line above. Argh. > > ;-) > aleem@pneumon:tmp-> grep '^Preview: Snippet' 1lyxpreview.log > Preview: Snippet 1 492688 0 744653) > Preview: Snippet 2 1441792 163840 16026923) > Preview: Snippet 3 282168 0 377591) > Preview: Snippet 4 1619363 449545 16026923) Urgh. > Could you further modify prlyx.cfg to not output that final ')'. Attached. > > Why has the name changed from .def to .cfg? Because I am an idiot. I posted from a different computer, and used the stuff decoded from my own letter, and had to give it a name, and gave it the wrong one. prlyx.def will, BTW, load a file prlyx.cfg if it happens to find one, so that the user may place configuration stuff of their own into a local or system-wide file. > I just pasted your .cfg file into your original .def file and all > works well. Should I rename this as .cfg? No, please don't, and be sure you don't have a prlyx.cfg lying around accidentally. When we are through with this, is it ok with you if I place prlyx.def into the preview distribution? It will in a later iteration also gather color support (or rather, the color support will generally included into preview.sty), but the current implementation should work fine then still, I suppose. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Preview: request for testers
Angus Leeming <[EMAIL PROTECTED]> writes: > On Friday 12 July 2002 9:12 am, David Kastrup wrote: > > Herbert Voss <[EMAIL PROTECTED]> writes: > > > Angus Leeming wrote: > > > >>Statistics: > > > >>285 numbered equations > > > >>732 pages in the metrics file > > > >>57 MBytes for the ppm-files > > > > > > > > Experiment with gs -sDEVICE=pnmraw. Does that reduce disk footprint > > > > much? > > > > > > yes, up 14.5 MBytes > > > > This is still ridiculous. Get this PNG support going. Of course, > > this also explains why previews got slower when color support got > > added: I/O time. ppm files take up three times more space than pgm, > > and when you leave off antialiasing, you get pbm, at another factor > > of 8 in file size. I/O time for 57MBytes is far from trivial. > > > > Get this PNG support going. > > David, I work on LyX for fun. I did not particularly address you. Hmmm, what was the reason I was working on LyX (if you would call it that)? > I do not have an infiinite amount of time to spend on it. Well, PNG image support will mean previews will be much more fun, and their loading will not spend an infinite amount of time... > On a more positive note, John Levon has an almost working Qt > frontend. That will "just work" with PNG. Hmmm. Image loading will depend on the toolkit used? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Is this the right preview info for LyX?
David Kastrup <[EMAIL PROTECTED]> writes: > If that's ok, just use grep, which will probably be faster. > > grep '^Preview: Snippet /' And do the obvious correction to the line above. Argh. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Preview: request for testers
Herbert Voss <[EMAIL PROTECTED]> writes: > Angus Leeming wrote: > > > >>Statistics: > >>285 numbered equations > >>732 pages in the metrics file > >>57 MBytes for the ppm-files > >> > > Experiment with gs -sDEVICE=pnmraw. Does that reduce disk footprint > > much? > > > yes, up 14.5 MBytes This is still ridiculous. Get this PNG support going. Of course, this also explains why previews got slower when color support got added: I/O time. ppm files take up three times more space than pgm, and when you leave off antialiasing, you get pbm, at another factor of 8 in file size. I/O time for 57MBytes is far from trivial. Get this PNG support going. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Is this the right preview info for LyX?
Angus Leeming <[EMAIL PROTECTED]> writes: > On Thursday 11 July 2002 11:10 pm, David Kastrup wrote: > > That regexp looks _slow_. And I am surprised that the + should not > > be interpreted specially. How about > > ended\.(\(-?[0-9]*\)\+\(-?[0-9]+\)x\(-?[0-9]+\))/\1 \2 \3 \4/p;d" < > 1lyxpreview.log > 1lyxpreview.metrics > > ;-) I just want something quickly. But thanks. I'll modify the script. > > > Anyhow: if you need your entries in a different format, there is no > > sane reason why I should not write them out immediately in the format > > you desire: this is a LyX-specific option, no need to make it more > > complicated for LyX to parse it than necessary. > > Great. If you output > Preview Snippet 1: 492688 0 744653 > Preview Snippet 2: 1441792 163840 16026923 > Preview Snippet 3: 282168 0 377591 > Preview Snippet 4: 1619363 449545 16026923 > I'd dump that straight into the .metrics file with > set -e "/Preview Snippet/p;d" < 1lyxpreview.log > 1lyxpreview.metrics I have moved the colon so that all diagnostics start with Preview: If that's ok, just use grep, which will probably be faster. grep '^Preview: Snippet /' And here is the corresponding prlyx.cfg: msg40858/tex0.tex Description: Next try. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Is this the right preview info for LyX?
Angus Leeming <[EMAIL PROTECTED]> writes:
> On Thursday 11 July 2002 1:51 am, David Kastrup wrote:
> > Take a look at the output when you run previews with the added "lyx"
> > option (it must come after the tightpage option, or it will fail to
> > report the additional bounding box adjustments from the tightpage
> > option).
>
> David, you're a star!
>
> Putting this in a script:
> #!/bin/sh
> FONTSIZE=`sed -e "s/Preview: Fontsize \(.*\)pt./\1/p;d" < 1lyxpreview.log`
> echo ${FONTSIZE}
> sed -e "/^Preview: Snippet/s/Preview: \(.*\)
> ended.(\(.*\)+\(.*\)x\(.*\))/\1:
That regexp looks _slow_. And I am surprised that the + should not
be interpreted specially. How about
ended\.(\(-?[0-9]*\)\+\(-?[0-9]+\)x\(-?[0-9]+\))/\1
> \2 \3 \4/p;d" < 1lyxpreview.log > 1lyxpreview.metrics
Anyhow: if you need your entries in a different format, there is no
sane reason why I should not write them out immediately in the format
you desire: this is a LyX-specific option, no need to make it more
complicated for LyX to parse it than necessary.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Is this the right preview info for LyX?
Take a look at the output when you run previews with the added "lyx" option (it must come after the tightpage option, or it will fail to report the additional bounding box adjustments from the tightpage option). prlyx.def Description: LyX preview definition file -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Preview.sty weirdness with labels
Angus Leeming <[EMAIL PROTECTED]> writes: > Sometimes the labels are at the front, sometimes at the back. See attached > LaTeX file and resultant bitmaps. > > David, have you any ideas about this? Has Kornel found a bug? AMSLaTeX does not support the eqnarray environment, so it gets inconsistent markup and spacing as compared with other math (perhaps AMSLaTeX should actively disable those LaTeX constructs it does not support). Since the mechanisms for equation labels differ for AMSLaTeX and plain LaTeX, and since preview.sty has to cater in different ways for both, this leads to the shown results. The showlabels option is basically a simple convenience hack, and it had to be extended in order to support AMSLaTeX equations, in a different way. Trying to hack something into it for the sake of people that use wrong environments under AMSLaTeX is not a priority. I am aware that the results for supported LaTeX environments like "equation" will look different when loading amsmath, but since the output is merely supposed to somewhere tag the stuff for proofreading, I do not consider hunting for more consistent spacing a priority: the labels don't appear in the final version, anyway. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview and two new lyxrc variables
Angus Leeming <[EMAIL PROTECTED]> writes: > On Wednesday 10 July 2002 9:42 am, Jean-Marc Lasgouttes wrote: > > Angus> \preview_hashed_equation_labels with a default value of false. > > Angus> Set this to false to give "less confusing" labels. (to an > > Angus> easily confused person like me!) See attached. > > > > Wouldn't it be possible to get the labels inside parenthesis > > (eq:mylabel) instead of this confusing # business? Note that this is > > what mathed does... I do not know whether this should be done at > > preview.sty or lyx level. > > > > JMarc > > I don't think LyX's preview code should be very bright. If it does such > manipulations then it's having to be brighter than it should be. > > That leaves preview.sty. Since it already implements the feature in > one way, it might be possible to implement it another way if you ask > nicely. David? I find this much more confusing than anything else, and rather ugly, to boot. And it is not completely trivial to implement, I guess. One could start off the existing showlabels option. I certainly don't have the time currently to invest into this. If somebody wants to develop a suitable option, I'll be accepting appropriate patches to preview.dtx, or I can give anybody willing to do some LyX-related work on the preview stuff developer access on SourceForge. I am willing to help out with the basic stuff needed to get things working, even though it detracts from time I do not really have available, but I won't indulge into cosmetic details myself. I hope you can find this acceptable. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview - fontsize
Angus Leeming <[EMAIL PROTECTED]> writes: > On Tuesday 09 July 2002 3:46 pm, Jean-Marc Lasgouttes wrote: > > >>>>> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: > > > > OK, OK... So latex will be run on this file anyway? Why not write on > > the log file the values you are looking for? > > I think that /this/ is the right solution. I'd like the default > font size and the ascent, descent info written to the log file. > > The latter is needed for those (in the future) who use dvipng and so > cannot extract the info from the PostScript file. It'd be nice to > have a common approach. > > David, could you modify preview.sty appropriately? > You mentioned that you already right the ascent,descent info to the > log file for AucTeX I believe. Could we have a lyx option too? No change in preview.sty itself needed. If you call preview.sty with an option "lyx", it will look for and include a file "prlyx.def". That's similar to how the AUCTeX option is implemented. Since the dimensions are sort of internal stuff from inside preview.sty, I would prefer it if prlyx.def were ultimately distributed along with preview.sty instead of separately by you. That way, it would become easier to ensure that prlyx.def and preview.sty match. Of course, this would subject prlyx.def to the release cycle of preview.dtx, which currently has been identical to the preview-latex release cycle. If it turns out necessary to get a faster update, a separate release of preview.dtx from the rest of preview-latex might be possible. > In turn it is passed to gs to generate an appropriately-sized image. > > Were we to use dvipng, it would still be needed. Yup. So what do you want in there eventually? The AUC TeX option outputs the following: it raises an error message at the beginning and the end of each previewed part which serves as a source special pinpointing with character precision. I don't know whether LyX would ever be interested in LaTeX itself deciding what material to preview, and this is just interesting if indeed LaTeX (governed by possible configuration files) pinpoints those materials. The error message at the end of the preview outputs the three box dimensions of the TeX box (which has its baseline start exactly at the (1in,1in) mark). Now the tightpages option (which we currently don't use in preview-latex itself) would add additional, configurable margins to the box it tells PostScript to crop to. For correct ascender information, you would have to take those additional margins into account, too. The numbers are probably easiest processable as integers in the unit scaled points. It would also be possible to output them in the unit pt, but in that case the unit would be part of the output, and TeX's fixed point formatted numbers can contain errors as large as 0.5sp, which is almost 3nm. Ok ok, not so very tragic. The printed representation of those fixpoint numbers takes a bit more space in the log file than the integers, though. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview - fontsize
Herbert Voss <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>
> >>>>>>"Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
> >>>>>>
> > Herbert> the patch to get the default fontsize from the classfile if
> > Herbert> the "default" was chosen from inside LyX.
> > I see I am a tiny bit late becasue this is already in cvs, but I
> > would
> > have much preferred to add this information to the layout files,
> > rather than trying to read the .cls files. We are not even sure that
> > all class files have \ExecuteOption{... xxpt... }.
>
>
> this is absoluetely unimportant
>
>
> > What about just adding DefaultFontSize to ClassOptions? I will provide
> > the patch if herbert accepts that.
>
>
> and you are the man who will have a permanent look at CTAN when the
> default fontsize in any class changes and who will update a value,
> which is only useful for the mathpreview ... and (at this time) for
> nothing else.
Well, your method could still be applied for either
a) autogenerating the info put into ClassOptions
b) an automated verification process that could be run before a
release.
Of course, if some style changes over history, it will be difficult
to offer something consistent.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: Possible preview.sty feature request
Angus Leeming <[EMAIL PROTECTED]> writes:
> David,
>
> I wonder if it would be possible to add an option to preview.sty so that,
> when using "showlabels", equation labels are displayed as (#)?
>
> Attached are two screen shots of what happens now.
>
> preview1.png. I load an existing file into LyX. The labels already exist.
> Both snippets are sent to the same file, LaTeX is run and so the labels are
> numbered consecutively, (1) and (2). Great.
>
> preview2.png. I edit the second equation and regenerate the
> preview. A single LaTeX snippet is output to file, LaTeX is run. The
> result? The document has two equations (1). Not so great.
The document does not have two equations (1). The previews are
displayed with (1) in its place. Now either LyX has its own idea
about the equation numbers, in which case it could do
\setcounter{equation}{2}
before the region it sends through, or it hasn't. In that case you
can always do
\renewcommand{\theequation{\#}}
if you insist.
Of course, the layout will not correspond with the final one in case
that the equation number has definite influence on it, but that can't
really be cured without further complications.
If you really are into complications, you could at the initial run
output LaTeX checkpoints at the previews (the counter structure saved
by the \include/\includeonly mechanism) and restore them before
running single previews through.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: bug in image-preview
Herbert Voss <[EMAIL PROTECTED]> writes: > there is still the bug present, that the right pixels > are ignored. Are they in the ppm file? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: newest CVS- cannot compile
Andre Poenitz <[EMAIL PROTECTED]> writes:
> On Mon, Jul 08, 2002 at 04:41:00PM +0200, Kornel Benko wrote:
> > \begin{preview}
> > \begin{eqnarray}
> > - -\frac{1}{2}(n-1)c\lambda \Delta R & & \label{4_1_3}\\
> > =\sum _{\alpha }\sum _{i(\alpha )_{j}\right)^{2} & - & \left(\lambda -(n-1)R\right)\lambda ^{2}c+\sum
>_{\alpha }\left\Vert B(\alpha )_{ijk}\right\Vert ^{2}+\nonumber \\
> > & + & \frac{1}{n+2}\lambda c\{ 3\lambda ^{2}-4(n-1)\lambda R+2n(n-1)R^{2}\}
>;\nonumber
> > \end{eqnarray}
> >
> > \end{preview}
> > ...
> > ! Missing $ inserted.
> >
> > $
> > l.1098 ...n-1)c\lambda \Delta R & & \label{4_1_3}
> > \\
>
> Hm, are underscores allowed in labels?
Not explicitly. Labels may contain "character tokens", and an
underline sort of qualifies. The showlabels option from preview in
its not-yet-fixed-in-a-regular-release original way of working just
typesets the label as_is, and the underline gets in the way.
Sorry, I never promised you a rosegarden. Anyhow, since the label
showing makes the previews less "true", I recommend making it an
option you can turn on or off (after all, that is why it is an option
to preview.sty).
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: newest CVS- cannot compile
Angus Leeming <[EMAIL PROTECTED]> writes: > The really interesting quesion is why do things work when LaTeX is > run on the entire document but not when we're using preview.sty. Because of a bug fixed in the CVS. In a few days, I'll push 0.7.3. > David, are you reading this? I am afraid so. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: newest CVS- cannot compile
Kornel Benko <[EMAIL PROTECTED]> writes:
> On Monday 08 July 2002 16:32, Angus Leeming wrote:
> ...
> > > l.1098 ...n-1)c\lambda \Delta R & & \label{4_1_3}
>
> ...
> > Try modifying src/graphics/PreviewLoader.C
>
> Now it is ok. Of course, without labels. (Editing the lyx-file
> and changing "\label{4_1_3}" --> "\label{4\_1\_3}" cured it also.)
>
> Maybe (as Andre writes) because of underscores.
Should be fixed in the current CVS version of preview.dtx (fix went
in in April). I'll have to release 0.7.3 soon because of a f***up of
GNU GhostScript 7.05, and it will have this in there, too.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: Generating previewed snippets yourselves...
"Garst R. Reese" <[EMAIL PROTECTED]> writes: > Andre Poenitz wrote: > > > > On Mon, Jul 08, 2002 at 12:17:08PM +0200, Herbert Voss wrote: > > > >I usually scroll to the bottom of the doc and continue working from there. > > > >So "usually" I'll see most things jsut once, but I'll see them. > > > > > > and where is the sense to see all the tons of previews, > > > when your screen at the end shows only let's say up to 10? > > > > Not really much sense, but do you see an easy way out? How would the loader > > decide between "users stops here" and "user will scroll further down"? > > > > Maybe we could later cancle things from the preview queue, but I'd not do > > that before I see that this is necessary. > > > Why not have a preview toggle. There might even be events that > automagically toggle it, but there are times when I do a lot of > scrolling around looking for stuff that I forgot if I even wrote. A > simple way to toggle graphics and preview on and off (same toggle) would > be nice (for me). If you have a separate thread rendering previews, and this thread will never render anything that is already off-screen again, scrolling will not be braked by the image rendering process. One would have to think about a strategy where an image rendering is taking quite long after the image location has already been scrolled off screen, perhaps it would be worthwhile to abort in that case. But apart from that, things should be workable rather asynchronously. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview
Angus Leeming <[EMAIL PROTECTED]> writes:
> On Monday 08 July 2002 1:42 pm, Herbert Voss wrote:
> > Andre Poenitz wrote:
> > > On Mon, Jul 08, 2002 at 01:18:17PM +0200, David Kastrup wrote:
> > >>Uh, I just mentioned scartcl and scrlettr as _examples_ with a
> > >>different design size from the 10pt from standard LaTeX classes.
> > >>IIRC, most of the Koma classes have 11pt as default (except for the
> > >>letter classes in it which have 12pt).
> > >
> > > I think we do not have to get this right. Just use 11pt as "average" and
> > > we might be of by 10% about which I don't care. Slides are differently,
> > > though.
> >
> > it's no problem to get the default size from the classfile.
> > What I did was inly the first try with the most common classes.
> >
> > HErbert
>
> You mean use apply some regular expression to the LaTeX classfile?
>
> Alternatively, since this is for our own internal use, why don't we just
> specify
>
> os << "\\documentclass[10pt]{" << textclass << "}\n";
>
> ? Would that not be easiest?
Since the look of formulas set with AMSLaTeX, for example, very much
depends on the interaction between formula size and page margins,
previews are most useful when the preamble is mostly the same as for
the normal document. Instead of forcing options to the document
class, it would for that reason be better if LyX just knew about what
to expect from users' specifications.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: preview
Angus Leeming <[EMAIL PROTECTED]> writes:
> On Monday 08 July 2002 12:07 pm, Herbert Voss wrote:
> > Angus Leeming wrote:
> > > I think I'm going to be quite busy this week, so Herbert if you're
> > > interested would you like to have a go?
> >
> > attached.
> >
> > > That is, for \documentclass{article}, divide by 10pt, for
> > > \documentclass{scrartcl}, divide by 11pt, for
> > > \documentclass{scrlettr}, divide by 12pt, for
> > > \documentclass[xxpt]{anything}, divide by xxpt.
> >
> > it works now on my machine, but I suppose this this
> > may not be the same on others so that we need a lyxrc
> > variable to cirrect the view anyway.
> >
> > HErbert
>
> Well done, Herbert. Thank you. I'll shove this in.
Uh, I just mentioned scartcl and scrlettr as _examples_ with a
different design size from the 10pt from standard LaTeX classes.
IIRC, most of the Koma classes have 11pt as default (except for the
letter classes in it which have 12pt).
If you don't know this information from somewhere else (would LyX
adjust its display sizes to those of the document? Would probably
not make much sense in WYSIWYM, where the screen font size would
probably be more related to readability than the document size?), one
should perhaps try looking through the dozen or so of classes LyX
supports and check their defaults.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: Generating previewed snippets yourselves...
Andre Poenitz <[EMAIL PROTECTED]> writes: > On Mon, Jul 08, 2002 at 12:17:23PM +0200, David Kastrup wrote: > > Then you deserve the punishment you get. People which instead jump > > to the end of the document with a single cursor positioning command > > (I presume somthing like this exists) don't need to be punished > > likewise. > > LyX is a lousy text editor... typing 'G' certainly does not move to the end > of the buffer. If Ctrl-End would not do the trick, it would be much saner to implement that rather than promote Page Down as a substitute. It appears, however, that LyX is not quite as bad as you would think. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Generating previewed snippets yourselves...
Andre Poenitz <[EMAIL PROTECTED]> writes: > On Mon, Jul 08, 2002 at 11:54:29AM +0200, David Kastrup wrote: > > My pleasure. You don't want to load 1000 image files into LyX when a > > majority of them will never be displayed on screen since it is highly > > unlikely that a particular editing session will rediplay the entire > > document. Load them when you need them, not before. > > I usually scroll to the bottom of the doc and continue working from > there. Then you deserve the punishment you get. People which instead jump to the end of the document with a single cursor positioning command (I presume somthing like this exists) don't need to be punished likewise. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Generating previewed snippets yourselves...
Angus Leeming <[EMAIL PROTECTED]> writes: > On Monday 08 July 2002 10:24 am, John Levon wrote: > > On Mon, Jul 08, 2002 at 09:53:07AM +0100, Angus Leeming wrote: > > > I really like Lars' idea of a separate thread, especially if we combine > > > it with an intelligent queue so we can send off 40 equations or so at a > > > time. > > > > Do we really need a thread rather than a process ? > > I don't know. We want to load 1000 image files into LyX. We don't want the > user to wait for 5 minutes for this to occur. Sounds like a thread to me. > Tell me otherwise. My pleasure. You don't want to load 1000 image files into LyX when a majority of them will never be displayed on screen since it is highly unlikely that a particular editing session will rediplay the entire document. Load them when you need them, not before. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview
Andre Poenitz <[EMAIL PROTECTED]> writes: > On Mon, Jul 08, 2002 at 09:45:51AM +0200, Herbert Voss wrote: > > Here is a patch to enable the user to get the right > > font size for the previews. > > And we can't determine that factor from other settings? Default screen font design size, default document font design size (as per preamble used for generating the preview), screen resolution. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: label of equation with preview
geof <[EMAIL PROTECTED]> writes:
> Hi, the preview is a very nice feature!
>
> It is possible to put the label of the equation instead of his number :
> Replace
> \begin{equation} bal bla bla \label{eq:blabla} \end{equation}
> by
> \[ bal bla bla \eqno{ \rm{ (eq:blabla) }} \]
>
> It can be nice, no?
\PassOptionsToPackage{showlabels}{preview}
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: Generating previewed snippets yourselves...
Angus Leeming <[EMAIL PROTECTED]> writes: > I'm sure that the wizards will be able to help here. Wizards, are > you reading this? I'd like to generate small batches of these > previews, say for the first three or four screen > heights. Thereafter, if I arrive at an inset for which a preview > hasn't been generated, I'd like to generate previews for three or > four screen heights around it. Any thoughts on an interface? That's not what I meant. It is certainly quite a good choice to be generating all PNG files with a single LaTeX/DviPS/GhostScript run. It is not a good choice to be loading all those PNGs into memory when they are not needed. Let them sit on the disk until they are really displayed. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Generating previewed snippets yourselves...
Herbert Voss <[EMAIL PROTECTED]> writes:
> Angus Leeming wrote:
>
> whith the geometry-package loaded I got something like the attached
> gif. The equationnumber is outside of the
> workarea -> the (for the preview wrong) textwidth
> from geometry was taken for the image width.
>
> \usepackage{geometry}
> \geometry{blah ... blah}
>
> should be ignored in the preamble.
The dvips option of preview.sty tries to override any ugly
PostScript. Either try loading the preview style last, or load it
with the "delayed" option set.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: Generating previewed snippets yourselves...
Kornel Benko <[EMAIL PROTECTED]> writes: > On Friday 05 July 2002 23:08, Angus Leeming wrote: > > > I've just submitted my workings on the preview code to > > CVS. Attached is a screen shot of what you can now expect. As you > > can see, I've just about resolved the positioning of the preview > > on the screen. There may be an off-by-one problem. > > WOW!!! > > [snip] > > > follow the instructions in README-preview > > Opposed to the instruction in "README-preview" to reconstruct > preview.ins, it was sufficient to > > tex bootstrap.ins > tex preview-mk.ins > > to get the required files. The instructions in README-preview are for the standalone distribution of preview.dtx. preview-mk.ins differs from preview.ins mentioned in README-preview mainly in that the latter will install into TDS-compliant directories when an appropriate docstrip configuration exists, while preview-mk.ins will always unpack into the current directory in order to facilitate the usual make all && make install procedure. The standalone distribution of preview.dtx does not even come with bootstrap.ins; that is only present in the complete preview-latex distribution (which at the current point of time is definite overkill for use with LyX). The standalone preview distribution is at CTAN:macros/latex/contrib/supported/preview IIRC. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Generating previewed snippets yourselves...
Angus Leeming <[EMAIL PROTECTED]> writes: > You'll also need to grab a copy of preview-latex. I grabbed the most recent > stable version, preview-latex-0.7.2b.tar.gz from > http://prdownloads.sourceforge.net/preview-latex > > Actually, you'll need just the preview.sty .def and .cfg files that are > generated by > tar xvzf preview-latex-0.7.2b.tar.gz > cd preview-latex-0.7.2b/latex > follow the instructions in README-preview > Don't forget to install them someplace LaTeX can find them and remember to > run texhash or equivalent. Note that _this_ subset can be had from CTAN:macros/latex/contrib/supported/preview where CTAN is your favorite CTAN mirror (try finger [EMAIL PROTECTED] if you do not know about CTAN). No need to get the complete preview-latex stuff (unless you are curious). > Incidentally, if you load a document with LOTS of equations, don't expect to > see anything soon. We only load the images into LyX once gs has finished > generating ALL the bitmap files. > > I've just tried with a Thesis containing 617 equations. It took gs > about 5 mins to do the work. Thereafter LyX freezes until all these > images are loaded up into memory. That's not good. > I think we'll have to do something about that. Presumably the > elegant solution of loading an image file as it is created might > aleviate this problem somewhat. That's not a good solution. The good solution would be to load only those images that actually appear on-screen. Often in a single editing session, you will not even be looking at most of the document. No need to be loading the stuff into memory in the first place, then. And it sounds like thinking about some sort of persistency would be good. If you create a temporary directory with a name deriving from the main document, and you take some sort of basic timestamps from the document, it should be possible when restarting LyX to know whether one can keep the current previews or should regenerate. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview status update.
"Michael A. Koziarski" <[EMAIL PROTECTED]> writes: > Man, that Screen shot is cool! The research mathematician here is > drooling. If he be drooling over the difference of the already quite readable LyX rendition to the preview, you might imagine the drool preview-latex users have shed over the difference of plain ASCII input in Emacs and embedded previews. Anyhow, I am somewhat appalled at the quality of the _LyX_ math fonts on this screen shot: in particular the closing parens look like a wilful malicious attack on aesthetics. Is this some combination of vector fonts and low resolution rasterization at work? If any font wizard has some time to spare sometime, looking over the native screen font usage of LyX might also help improving readability. > I'm impressed how quickly this code has materialised, it's amazing > really! Agreed. Caught me quite by surprise, too. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview status update.
Andre Poenitz <[EMAIL PROTECTED]> writes: > On Fri, Jul 05, 2002 at 11:09:31AM +0200, David Kastrup wrote: > > How about that: set up a poll page where users can actively select all > > options they think worth having as default, or where they don't mind. > > If somebody does want to have something changed he should file a > feature request no bugzilla. I would suppose that there are a lot of setting where people would choose a different default, but don't consider the chosen setting an actual "bug" or worth reporting as long as one can customize them away. It sometimes might be worth getting an opinion apart from "this is absolutely intolerable". And even if somebody reports something as "absolutely intolerable", you have no way to find out whether this is the tip of an iceberg or a mole hill. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview status update.
[switched back to list, since this has become on-topic again, hope you won't mind] Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > No, they are drawn 'by hand' with lines, I believe. However, someone > decided that the right delimiter should be inferred from the left > one using a rotation matrix, and there are serious rounding errors > in the code involved. Rounding errors? When rotating by 180 degrees? In that case I think it likely that thinking over the involved code and the method of when to round and where, and running it again, might do a lot of good, probably for quite a few characters. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: preview status update.
Andre Poenitz <[EMAIL PROTECTED]> writes: > On Fri, Jul 05, 2002 at 10:36:13AM +0100, Jules Bean wrote: > > > I'll define an LColor::preview and you can do as you like. > > > > LColor::mathpreview? > > No. > > > If LColor::math wants to be different from LColor::foreground, then > > LColor::mathpreview will want to be different from a (putative) > > LColor::preview. > > *sigh* And I am trying to get rid of the mathed/main LyX schism... A split here would not make sense. Preview is preview: in either case, it reflects what LaTeX would produce, and it has no inner editable structure for LyX. So I think a single LColor::preview is the right thing to use, and it would be distinctly awkward to let it default to the math colors once non-math previews get added. I would let it default, so to say, to a symbolic link to text foreground color: as long as the user does not specify otherwise, let it follow the text color settings, even if the user changes those. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: size of compiled lyx
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: > David Kastrup <[EMAIL PROTECTED]> writes: > > | Herbert Voss <[EMAIL PROTECTED]> writes: > > > >> can somebody please explain, why using the gcc 3.1 > >> stops the bloat of the compiled lyx? > > > | IIRC, they had some changes in the default debug format (this would > | probably not apply if you stripped executables), and they have had > | changes in the C++ API (for example, template handling). > > Yes, but the change in the debug format should increase the size, > right? * The default debugging format for most ELF platforms (including GNU/Linux and FreeBSD; notable exception is Solaris) has changed from stabs to DWARF2. This requires GDB 5.1.1 or later. I have not found anything definite about size, except that people complained about dwarf2, and that there was something going to be changed. That was in some news from year 2000. Whether anything actually did change, and whether this might have been reason for the switch to dwarf2, I have no idea. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: size of compiled lyx
Herbert Voss <[EMAIL PROTECTED]> writes: > can somebody please explain, why using the gcc 3.1 > stops the bloat of the compiled lyx? IIRC, they had some changes in the default debug format (this would probably not apply if you stripped executables), and they have had changes in the C++ API (for example, template handling). In general, with gcc C++ has been an area under quite more change and development than C recently. I have found the code generator to get better code with the f77 frontend even when applying the "restrict" keyword in C lavishly, so you might consider switching LyX to Fortran. Ok, that was a joke, but so is what pointer aliasing does to generated code quality with both C and C++. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: 1.3.0
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > >>>>> "David" == David Kastrup <[EMAIL PROTECTED]> writes: > > David> How strict is the distinction development/release branch > David> anyway? With Linux, it is usual that something is, i.e., "1.3 > David> material". That does not mean that it will be complete and > David> functional with 1.3.0, but that it will not impact the code > David> base in 1.2.x. And in a developers' version (like 1.3.x) > David> usually no attempts are made to keep things out of the code > David> base that are non-functional yet, as long as one can still > David> compile something workable, and as long as no feature freeze > David> has been announced. > > Actually, we do not use a stable/unstable versionning system. So 1.3.0 > will be the next stable release. Does that answer your question? Over and out. Sorry for the confusion. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Where's the best place for this?
Angus Leeming <[EMAIL PROTECTED]> writes:
> The preview stuff needs to ascertain the foreground and background
> colours of the LyX screen as a "fafb00" style string.
Uh, it doesn't necessarily: PostScript takes real numbers. That was
just a suggestion I gave. Instead of
{255 div}forall
You could also write
[64250 64507 0]{65535 div}forall
or
[16#fafa 16#fbfb 16#]{65535 div}forall
You have to be aware, though, that most image formats reduce the
resolution to 24bits per pixel, anyhow, and perhaps you would rather
want to make sure that they arrive at the same colors as the color
quantization LyX does for the screen in question.
In particular if you do any kind of gamma correction...
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: 1.3.0
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > >>>>> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: > > Andre> On Wed, Jul 03, 2002 at 04:17:23PM +0200, Jean-Marc Lasgouttes > Andre> wrote: Actually I don't even see that as a must. Would be nice, > Andre> though. > >> What would be the new features in 1.3.0 if nother frontend is not > >> operational? > > Andre> Good question. > > Andre> The preview stuff perhaps? > > I thought it was always clear that GUI-I was _the_ 1.3.0 feature. How strict is the distinction development/release branch anyway? With Linux, it is usual that something is, i.e., "1.3 material". That does not mean that it will be complete and functional with 1.3.0, but that it will not impact the code base in 1.2.x. And in a developers' version (like 1.3.x) usually no attempts are made to keep things out of the code base that are non-functional yet, as long as one can still compile something workable, and as long as no feature freeze has been announced. With that kind of policy, 1.3.0 would mean a basically working release with as much new stuff crammed in that can be put there without compilation/execution failing completely. If it fails completely, no point in assigning a release number. If it basically works, no point in not assigning a release number. Regardless of what just happened to work first. So while most certainly GUI-I _will_ be a required part of 1.4.0 (or 2.0, or whatever stable release is coming up next), I don't see the same requirements for 1.3.0, as long as developers do not get sidetracked too much just by preparing a "release". I mean, if 1.3.0 is to contain everything planned for 1.4.0, you could start a feature freeze right after 1.3.0. Or am I babbling? Would not be too uncommon an occurence... -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: background loading
Angus Leeming <[EMAIL PROTECTED]> writes: > It looks to me that of the three preview-latex modules > * preview.sty > * dvipng > * preview.el > the first two are usable directly by LyX and the logic of the > controller, preview.el, is similar to that that's now in LyX (I base > that on your description of how it works). So there is every chance > for us to grow together. You never know, you might be able to use > some of LyX's logic to your own advantage. dvipng currently is more or less proof-of-concept, and based on the dvihp printer code base (something which I personally would not have done myself, but on the other hand, given my perfectionism, I probably never would have gotten anything off the ground in a reasonable time frame, anyhow). In particular, this means that currently a) it does not support virtual fonts b) there will probably be other shortcomings in font handling (such as Type1 fonts or so) c) the code is really old basically and this shows d) I would be afraid that it will probably barf on Omega fonts e) antialiasing in its current form is not too hot, and characters can be placed only with target pixel resolution f) it requires the gd library without doing too much with it g) it might be a good idea to migrate DviPS/GhostScript operation on images requiring them into dvipng h) it does not yet support non-integral shrink factors. I have a good plan for how to implement those using lookup tables (I would imagine real-time resizing of xdvi-like windows possible with the technique I'll use for that). If g) gets implemented, dvipng will be a rather complete component usable both from within LyX as well as preview-latex, and will also be usable in systems that don't have the full-blown converter infrastructure LyX and preview-latex have or are about to get. So I guess that we would be happy if people decided to help work on the dvipng code base, either by starting something more sound from scratch, or by tackling some subtask on the existing code base. I think it rather likely that any functionality added into it for the sake of either preview-latex or LyX should be exploitable by the other system. And of course I'll be glad to stick LyX-specific configuration stuff into preview.dtx if that turns out feasible. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: using preview.sty
Angus Leeming <[EMAIL PROTECTED]> writes: > On Tuesday 02 July 2002 2:22 pm, David Kastrup wrote: > > Angus Leeming <[EMAIL PROTECTED]> writes: > > > On Tuesday 02 July 2002 2:13 pm, David Kastrup wrote: > > > > Angus Leeming <[EMAIL PROTECTED]> writes: > > > > > For now, this works well enough and is pretty fast: > > > > > pngtopnm trial004.png | pnmcrop - > trial004.ppm > > > > > > > > > > (It has the additional advantage that xforms won't currently load png > > > > > natively, so we must do the conversion anyway ;-) > > > > > > > > No. If you are forced to go through an external pnm file, you would > > > > of course directly use the pnmraw device of GhostScript, not the > > > > png16m device. > > > > > > I do. You're off the pace ;-) > > > > Well, it just occurred right now to me. Sorry to be too slow-witted > > for serious LyX development. > > N! You're the wizard, remember. I'm just the apprentice. Vat a pity zat nobody todays be interested in doing zeir apprenticeship in ze venerable discipline of Emacs Lisp. (excuse the heavy wizardly accent influx from an arcane tongue) -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: using preview.sty
Angus Leeming <[EMAIL PROTECTED]> writes: > On Tuesday 02 July 2002 2:13 pm, David Kastrup wrote: > > Angus Leeming <[EMAIL PROTECTED]> writes: > > > For now, this works well enough and is pretty fast: > > > pngtopnm trial004.png | pnmcrop - > trial004.ppm > > > > > > (It has the additional advantage that xforms won't currently load png > > > natively, so we must do the conversion anyway ;-) > > > > No. If you are forced to go through an external pnm file, you would > > of course directly use the pnmraw device of GhostScript, not the > > png16m device. > > I do. You're off the pace ;-) Well, it just occured right now to me. Sorry to be too slow-witted for serious LyX development. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: using preview.sty
Angus Leeming <[EMAIL PROTECTED]> writes: > For now, this works well enough and is pretty fast: > pngtopnm trial004.png | pnmcrop - > trial004.ppm > > (It has the additional advantage that xforms won't currently load png > natively, so we must do the conversion anyway ;-) No. If you are forced to go through an external pnm file, you would of course directly use the pnmraw device of GhostScript, not the png16m device. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: using preview.sty
Angus Leeming <[EMAIL PROTECTED]> writes:
> On Tuesday 02 July 2002 11:06 am, Andre Poenitz wrote:
> > > I've tried to define a converter that can be used by both the batch
> > > processor and by the image loader. Ie, it'll work for both multiple and
> > > single images.
> >
> > Fine.
>
> Hmmm. Here "gs" seems very slow now that is has the color info to
> deal with.
Unlikely. I rather suspect antialiasing. You can reduce the
-dTextAlphaBits value to 2 for a somewhat better performance at some
loss of quality. Leaving it off will make the stuff definitely more
ugly, though, albeit quite faster.
> It'd be nice if dvipng could deal with this direct since it's this final
> ps->bitmap step that is expensive.
dvipng works with colors and antialiasing, and it is very fast as
compared to GhostScript according to its main author Jan-Åke. I am
really mad at not yet having the preview-latex infrastructure
finished for making use of it. Only problem up to now is that it has
just integral shrink factors, but once I have got it in, I will take
a stab of changing this, too.
> Because math-macros are dumped into the LaTeX file after the
> begin{document}. Why is that?
Uh, good question. Why would that be?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: using preview.sty
Andre Poenitz <[EMAIL PROTECTED]> writes: > On Tue, Jul 02, 2002 at 10:45:02AM +0100, Angus Leeming wrote: > > I'm of the same opinion; we need this only when a document is > > loaded. But we still need to dump the preamble if we're to get > > user-defined macros et al. > > I though Herbert did some work on that part. > > Note that "the preamble" is not sufficient anyway. We would need > "local" defines etc as well to make it "Right"... Well, if you have any mechanisms for xdviing/ghostviewing just part of a document, "local" defines will fail anyway if not included in such a region. I would class operation of previews similarly: defs relevant to a preview should be placed either in the preamble, or inside of the previewed material itself. Catering for more is being too clever, I think. Let the user suffer the consequences. > > We need to split Buffer::makeLaTeXFile into two so that we can > > just grab the preamble. Thereafter, the PreambleQueue class is > > finished too I believe. > > As I said, local defines would break that scheme. But I think we > currently don't have the infrastructure to work around this problem. I think it should be a reasonable requirement to the user to behave himself in this regard. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: using preview.sty
Andre Poenitz <[EMAIL PROTECTED]> writes:
> On Mon, Jul 01, 2002 at 08:06:34PM +0100, Angus Leeming wrote:
>
> > I'm trying to use David's preview.sty so that we can generate all
> > the previews in one go when the document is loaded. Much quicker
> > than running a script on each one.
>
> Actually I think that's the only time we need to batch
> things. During "normal operation" the preview generation seems to be
> fast enough to be done one by one, so maybe we don't need that
> fullfledged "run queue" at all.
Depending on the update policy, the previews might, during "normal"
operation, be requested one by one, anyway.
> > The only two things I'd still like to do are be able to set the
> > colors of foreground/background to be the same as LyX's and to set
> > the font size to be the same as LyX's.
>
> Cosmetics. Make it a black background and call it a feature ;-)
Don't underestimate cosmetics. In particular, there are visually
impaired people that work white-on-black. Not catering for the
colors will cause appalling displays, both with inline graphics
(because it clashes left/right) as with displayed material (because
of its size, its quite ugly, too).
Trust me, users will _demand_ to have a good match of sizes and
colors. And they will want to see the preview instead of the
original (not tacked somewhere close to it). And, that's one
remaining problem, they will want to have the descenders of inline
math correct.
The tightpages option places the complete TeX bounding box (among
other information) into the PostScript file.
It would probably be easiest to extract it from there. We have the
following regexp for parsing DSC comments:
%%\(?:\(BeginDocument:\)\|\(EndDocument[
]\)\|\(Page:\)\|\(Trailer[
]\)\)
In case this does not survive transmission: the [] pairs enclose both
a CR and a LF: PostScript files may have their lines separated by
either CR, LF, or CRLF. This is important if EPS files from
different sources are included. Inside of BeginDocument/EndDocument
all comments exception BeginDocument/Enddocument are ignored, this is
for EPS file nesting. The top-level Page: comments should be
followed by DviPS' setup line, followed by 7 integers indicating the
bounding box info. The first four numbers are for extending the
PostScript Bounding box dimensions. The last three numbers are the
TeX dimensions, in order height, depth, width.
All of the dimensions are whole numbers in TeX's sp unit. With
regard to the calculations involved, here are the respective comments
from preview.dtx:
%Ok, here comes the beef. First we fish the 7~numbers from the
%file with |token| and convert them from \TeX~|sp| to PostScript
%points.
%Next we produce the horizontal part of the bounding box as
%\[ (1\mathrm{in},1\mathrm{in}) +
%\bigl(\min(|\wd\pr@box|,0),\max(|\wd\pr@box|,0)\bigr) \]
%Next is the vertical part of the bounding box. Depth counts in
%negatively, and we again take $\min$ and $\max$ of possible extents
%in the vertical direction, limited by 0. 720 corresponds to
%$10\,\mathrm{in}$ and is the famous $1\,\mathrm{in}$ distance away
%from the edge of letterpaper.
%Ok, we now have the bounding box on the stack in the proper order
%llx,lly, urx, ury. We add the adjustments:
So if the seven numbers are bllx blly burx bury ht dp wd, then the
resulting total height should be
max(0,ht,-dp)-min(0,ht,-dp)+bury-blly, and the baseline is situated
at -min(0,ht,-dp)-blly from the bottom, or at max(0,ht,-dp)+bury from
the top. All dimensions in scaled points.
If you think it too harebrained to have to fish the stuff from the
PostScript file (but parsing it will give you the necessary file
positions for passing the images through reordered, too, so as to be
able to treat the ones on display first), we can also make a
LyX-specific interface that would write the dimensions into the log
file (which is part of what preview-latex does with its auctex option,
too, but which is probably overkill for LyX use).
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: using preview.sty
Angus Leeming <[EMAIL PROTECTED]> writes:
> On Monday 01 July 2002 8:37 pm, David Kastrup wrote:
> > One solution: after loading the package preview, issue
> > \AtBeginDocument{\AtBeginDvi{%
> > \special{!userdict begin/bop-hook{//bop-hook exec
> > <343434656565>{255 div}forall setrgbcolor
> > clippath fill setrgbcolor}bind def end}}}
> >
> > Where the 343434656565 is the rrggbbrrggbb hex string for foreground
> > and background.
>
> David, you're obviously a wizard.
An absent-minded one, at best. My first suggestions did not work at
all. I am glad that this finally did it (I have to admit that I
didn't actually test it, either). But it's really very
straightforward PostScript. Hard to do this any simpler.
> This works beautifully.
Well, it makes the source file singularly ugly and cryptic (ok, it
probably is not intended for human consumption, anyway). I think that
eventually we will have a proper interface for the basic color setup
in preview.sty (I would want to avoid using color.sty if possible,
although trying not to interfere with its operation in case the
document uses colors) instead of doing it by hand per image as we
currently do in preview-latex (the first PDFLaTeX enabled version of
preview-latex will need this kind of stuff, too, mainly because I
would not know how to deal with daemon mode operation for GhostScript
on PDF files, since I have no clue at all concerning PDF).
But I think it should be reasonably easy to ensure that the above will
keep working fine even when a proper interface becomes available
eventually.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
Re: using sigmals
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: > But you loost all the semantics for this particular signal right? Well, I can't get oozed to people writing "to loose" and "looser" (except in contexts like "my trousers have become looser", rare enough), but "loost" is a noon for me. Was this on papoose? (This post approved by aspell, except for "loost" and "aspell"). -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: using preview.sty
Herbert Voss <[EMAIL PROTECTED]> writes: > Herbert Voss wrote: > > > shown with the attached gif. A simple sed-command in the > > shell-script > > > second try with use of gs. first image the old one, the second the > gs-one Well, the bright fringes are gone, but whatever happened to the prime marks? The first looks too vertical, and those on the right are missing completely. Also, it looks as though the braces might be a tadbit thicker, but this may also be due to the different color used as anti-aliasing background. If the corresponding LaTeX is the same, and GhostScript options also (except for the color code), then this needs some more investigation. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: background loading
David Kastrup <[EMAIL PROTECTED]> writes: > > > > Thereafter, the black box that is LyX's "run queue" sounds very > > similar indeed to preview-latex. Does it not run as a forked process > > and tell emacs when to load an image? > > Uh, not really. [Details snipped] I explained in detail what we do but got sidetracked and forgot to pinpoint the difference. Emacs is in control here completely and initiates the conversion, some of which is done in batch stages working on all images of one preview run, and the last of which (GhostScript) works on per-image basis. GhostScript just tells Emacs when it has finished another image. We basically have a queue of images that need to be rendered, and this gets filled in the first place as follows: Emacs under user control runs a region or file with preview.sty active through LaTeX. The output of this run determines where and what images gets placed: it fills the run queue and replaces all of the source sections by "work under construction" signs and enters each of them into the basic work queue. Then the whole queue gets worked off. Emacs' redisplay code calls a redisplay hook whenever it displays one of the "work under construction" signs on the screen, and this moves the image in question to the front of the work queue, so that it gets rendered with priority. Emacs basically converts all images and places them in the buffer. A display image property specification for Emacs can point to a graphics file (in our case, preferredly png). When this image appears on-screen, Emacs still needs to load it, but this is fast as compared to the other conversion stuff. So with Emacs, we have no "forked process" telling it when to load an image. The converters basically convert _everything_ Emacs cannot load natively until they are in a "fast" format. They can be made to start their work on the "important" images (on-screen), and this may change dynamically as the user pages through the file with unfinished images. But in the end, we convert everything, and the order might be determined by Emacs' redisplay, but not a forked process. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: background loading
Angus Leeming <[EMAIL PROTECTED]> writes: > What we need to do is to gather together a number of snippets into Andre's > "run queue" and then fork this off as a separate process. Let's treat this as > a black box for now > input: X latex snippets > output: X bitmap image files that will be produced at different times. > > The devlopment work that we need to do within LyX then is to modify > our "forked call controller" class so that it can deal with events > from a running process, not just tell us "the process has finished, > now deal with it". > > Thereafter, the black box that is LyX's "run queue" sounds very > similar indeed to preview-latex. Does it not run as a forked process > and tell emacs when to load an image? Uh, not really. The current implementation runs LaTeX with preview.sty on the region or document to be examined. The "auctex" option to "preview" spews out error messages for the beginning and the end of every element it finds displayworthy. Those error messages allow Emacs to pinpoint the cursor locations where previews originated in order to replace their source text with a preview. The usual manner of working is: 1. run LaTeX in background. 2a) run an Emacs procedure that analyzes the error messages from the LaTeX run, determines all locations of previews in the source text and prepares the Emacs data structures for inserting them 2b) run Dvips on the DVI file in background When both 2a and 2b have finished, we continue with 3) Parse the PostScript file for DSC comments in order to find PostScript Prolog and page locations in the source file. 4) run GhostScript in a pipe. Whenever GhostScript issues a prompt, we feed it new parameters for the next "page" (dimensions, colors and stuff) and insert a possibly finished "page" into the Emacs buffer. Errors lead to GhostScript being killed and a new one started with the old prolog, while the error generating particular preview gets replaced by clickable links to error message and location in PostScript file. If GhostScript bombs out before starting on a snippet, the run is aborted completely, with the error message being inserted into the general log file buffer. This interplay is currently rather hardwired. I am currently working on rewiring the logic. Emacs does not really fork itself except for executing programs. It is not multithreaded. It has a sort of synchronous multitasking, however, that can call sentinels (when a separately started executable finishes or gets killed) and filter routines (when a separately started executable has produces output). This makes it possible to let separate programs be run more or less in background as long as they are separate executables. Longterm plans are to make the various stages in such a conversion be submodules, that way making it easier to replace DVI by PDF, or Dvips and GhostScript with dvipng, and even LaTeX+preview.sty by different DVI producers (prepping up TeXinfo and Emacs calc with TeX images would become more feasible). > Are we gettting warmer/closer together? Well, we probably have similar rendering pipeline functionality to implement, but we will have a completely different code base for the pipeline stuff itself. It will take some time until I have that cooked out well enough and versatile and flexible enough for most purposes under preview-latex. When it is finished, it might or might not be interesting for you to take a look at what will then constitute a method in our pipeline stages, and of course, the actual strings that get sent to and interpreted from external programs might also be worth taking (I have already picked out quite a bit from the stuff that we use and tried to make it apply for your purposes, hopefully without getting too much of it wrong). In short, I guess you are on the right track to get things right more or less at first try. I'd sure like to be as effective as you are. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: using preview.sty
Herbert Voss <[EMAIL PROTECTED]> writes: > Herbert Voss wrote: > > > Angus Leeming wrote: > > > >> The only two things I'd still like to do are be able to set the > >> colors of foreground/background to be the same as LyX's and to set > >> the font size to be the same as LyX's. > >> As you can see, I've been unable to set the colors. > > should be a simple change of the "white" into > > the LYX-background "#??" of the xpm-file. > > > shown with the attached gif. A simple sed-command in the > shell-script This is not a good idea because of antialiasing, where edges attain a color between back- and foreground. The pixels that have a mixture will not be affected by your sed command. If you look closely at the image, you'll notice some light fringes around some edges of some characters, because the antialiasing happened with white instead of the background color. It really is a better idea to make GhostScript know about the colors. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: using preview.sty
Herbert Voss <[EMAIL PROTECTED]> writes: > Angus Leeming wrote: > > > The only two things I'd still like to do are be able to set the > > colors of foreground/background to be the same as LyX's and to set > > the font size to be the same as LyX's. As you can see, I've been > > unable to set the colors. > > > should be a simple change of the "white" into > the LYX-background "#??" of the xpm-file. > > > > I guess that the latter task is a question of setting gs' -r option > > using the info > > \screen_dpi 95 > > \screen_zoom 130 > > > the x option of dvips Better to use the scaling from GhostScript, at least if you are using antialiasing (and typical TeX fonts will not be suitable for screen resolution without this). Scaling in dvips implies generation of new fonts when using bitmap fonts, and does not buy you anything over scaling in GhostScript when using vector fonts. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
