auctex-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[AUCTeX-devel] Re: Web site update


From: Ralf Angeli
Subject: [AUCTeX-devel] Re: Web site update
Date: Sun, 17 Apr 2005 14:04:07 +0200
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/22.0.50 (gnu/linux)

* David Kastrup (2005-04-17) writes:

> This looks good.  Some minor points: I am not sure whether
> preview-latex should get its own menu entry in the overview instead of
> just being linked to from the "intro" and "features" page: it appears
> strange to mention it separately from "features" since it is a
> feature.

In contrast to the other features it is not yet 100% built-in and
still available separately which makes it special.  So I thought a
separate menu entry would be warranted, even if it looks a bit out of
place.  I don't have a strong opinion an this one, though.

> Then obviously it is strange that the screen shots for open and closed
> previews show completely different areas of the text.  This makes it
> harder to compare the effects.

I was desparately searching for an example which is suitable for that.
It should show hard to read code in the untreated case and a clean
display after generating the previews.  circ.tex does not offer this
too well.  I might use the part shown in the first screenshot as well
for the second but then you cannot see a section heading being
previewed.  In addition it is not really good that the file is written
in German.  Maybe I can find better examples on CTAN ...

> I don't think that links from the
> small extracts to the whole screen are useful: this is not a matter of
> thumbnails, and clicking will distract from the reading.

I was particulary after that "cinematic" effect of a short but wide
screenshot.  This does not leave too much room for showing everything
important.  So I'd like to stick with links to full screenshots.

> I'd place corresponding screenshots of open and closed previews
> directly after another without explaining text.

I'll have to see how this goes along with the descriptive text.  I
also thought about placing such before/after shots side by side.  But
this probably is not such a good idea due to the limited horizontal
space.

> In fact, where
> JavaScript was available, I would be tempted to make the change with
> mouse-over in the same place.

Even if we could rely on JavaScript being present, I find it more
illustrative to have both versions displayed at the same time.

> The PStricks screenshot is confusing since it seems to imply that
> _both_ text and image are visible at the same time.  I'd split it into
> two shots again.

Hm, yes, that would also improve the problem with limited space.  I
first had the code below in an lstlisting environment which would have
made it clearer but required an additional line of code.

>> The wording on the new page feels a bit clumsy sometimes, so
>> improvements on that are welcome.  And I am still searching for a
>> good pstricks example which shows something else than math and
>> doesn't require to install a whole bunch of additional packages.
>> Also it should look somewhat decent in the 80-pixel-high cutout.
>
> Perhaps something from the PStricks documentation itself?

The examples in the user's guide are all in grayscale and not
particularly interesting.  I found some nice stuff in
<URL:ftp://ftp.dante.de/tex-archive/graphics/pstricks/contrib/pst-vue3d/vue3d-e.pdf>
(Warning: 3.8MB) but haven't yet installed all the necessary pstricks
packages to actually generate a preview.  Also, many nice examples
suffer from being cropped in the Emacs buffer which would not be the
best thing for a showcase.

-- 
Ralf





reply via email to

[Prev in Thread] Current Thread [Next in Thread]