Re: Using \textcolor and \marginpar together
Piet van Oostrum
>CR> Hi,
>CR> I have encountered a problem using \textcolor and \marginpar together. The
>CR> following document illustrates the problems. When processed with latex, I
>CR> get a DVI which shows the correct colours in xdvik. However, when processed
>CR> with pdflatex, the PDF file only shows blue text on the first line of the
>CR> blue section.
>CR> Can anyone suggest a fix for this?
PDFTeX doesn't have a color stack. There is a package pdfcolmk that solves
the problem at page boundaries, but unfortunately it doesn't help in this
case. I don't think you can do much more than manually putting additional
\color{blue} declarations at the place where it goes wrong. UGLY!!!
If you don't want to exactly find out where the page break is, a
\vadjust{\color{blue}} will be easier (e.g. after the \marginpar). Most of
the time it will have the proper effect.
--
Piet van Oostrum <pi...@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: pi...@vanoostrum.org
Piet van Oostrum
>CR> Hi,
>CR> I have encountered a problem using \textcolor and \marginpar together. The
>CR> following document illustrates the problems. When processed with latex, I
>CR> get a DVI which shows the correct colours in xdvik. However, when processed
>CR> with pdflatex, the PDF file only shows blue text on the first line of the
>CR> blue section.
>CR> Can anyone suggest a fix for this?
PDFTeX doesn't have a color stack. There is a package pdfcolmk that solves
the problem at page boundaries, but unfortunately it doesn't help in this
case. I don't think you can do much more than manually putting additional
\color{blue} declarations at the place where it goes wrong. UGLY!!!
Chris Rodgers
I have encountered a problem using \textcolor and \marginpar together.
The following document illustrates the problems. When processed with
latex, I get a DVI which shows the correct colours in xdvik. However,
when processed with pdflatex, the PDF file only shows blue text on the
first line of the blue section.
Can anyone suggest a fix for this?
Many thanks,
Chris Rodgers.
Test document:
\documentclass[a4paper]{article}
\usepackage{color}
\begin{document}
\section{Testing}
This is a test! \marginpar{\textcolor{red}{This should be red.}}
\textcolor{blue}{This should be blue. This should be blue. This should
be blue. This should be blue. This should be blue. This should be
blue. This should be blue. This should be blue. This should be blue.
This should be blue. This should be blue. This should be blue. This
should be blue. This should be blue. This should be blue. This
should be blue. This should be blue. This should be blue. This
should be blue. This should be blue. This should be blue. This
should be blue. This should be blue. This should be blue. This
should be blue. This should be blue. This should be blue. This
should be blue. This should be blue. This should be blue. This
should be blue. This should be blue. This should be blue. This
should be blue. This should be blue. This should be blue. This
should be blue. This should be blue. This should be blue. This
should be blue. This should be blue. This should be blue. This
should be blue. This should be blue. This should be blue. This
should be blue. This should be blue. This should be blue. This
should be blue. This should be blue. This should be blue. This
should be blue. } And this should be back to black.
\end{document}
% Local Variables:
% TeX-master: t
% End:
Chris Rodgers
> the problem at page boundaries, but unfortunately it doesn't help in this
> case. I don't think you can do much more than manually putting additional
> \color{blue} declarations at the place where it goes wrong. UGLY!!!
> If you don't want to exactly find out where the page break is, a
> \vadjust{\color{blue}} will be easier (e.g. after the \marginpar). Most of
> the time it will have the proper effect.
This seems a rather basic omission. Can I assume that it is already on
someone's TODO list, or should I report this somewhere?
Chris.
Jonathan Fine
I don't know how widely known this problem is. It certainly surprised me.
Then, I'm not a pdftex user. I just expect it to behave in certain
ways, based on my use of TeX.
You're right, though, it is something of a basic omission.
It's not so easy to report bugs to the official location. I tried to
recently with an error (in my opinion) relating to \pdfinfo.
The pdftex project on sarovar has very tight permissions, and so I had
to ask a developer to report the bug for me.
Here's my message to the group about this:
<http://groups-beta.google.com/group/comp.text.tex/msg/26f8f6f78cbc589f?hl=en>
--
Jonathan
Piet van Oostrum
>>> PDFTeX doesn't have a color stack. There is a package pdfcolmk that solves
>>> the problem at page boundaries, but unfortunately it doesn't help in this
>>> case. I don't think you can do much more than manually putting additional
>>> \color{blue} declarations at the place where it goes wrong. UGLY!!!
>>> If you don't want to exactly find out where the page break is, a
>>> \vadjust{\color{blue}} will be easier (e.g. after the \marginpar). Most of
>>> the time it will have the proper effect.
>CR> This seems a rather basic omission. Can I assume that it is already on
>CR> someone's TODO list, or should I report this somewhere?
It has been known for several years.
Robin Fairbairns
>Then, I'm not a pdftex user. I just expect it to behave in certain
>ways, based on my use of TeX.
if you experience tex doing colour right, it's very little to do with
knuth: it's tom rokicki's colour stack, typically used by david
carlisle's latex color.sty
>You're right, though, it is something of a basic omission.
which is no doubt why don didn't include the facility in tex itself.
the fact is that pdftex took over the tex model, and it shouldn't
have: what was needed is colour as a glyph attribute. i've never
heard of that being discussed as a practical possibility; though
yannis haralambous had colour as a sign attribute in his eurotex talk,
iirc.
--
Robin (http://www.tex.ac.uk/faq) Fairbairns, Cambridge
Jonathan Fine
> Jonathan Fine <jf...@pytex.org> writes:
>
>>Then, I'm not a pdftex user. I just expect it to behave in certain
>>ways, based on my use of TeX.
>
>
> if you experience tex doing colour right, it's very little to do with
> knuth: it's tom rokicki's colour stack, typically used by david
> carlisle's latex color.sty
I agree. Knuth provided the \special mechanism and, as he intended,
others took advantage of it.
>>You're right, though, it is something of a basic omission.
>
>
> which is no doubt why don didn't include the facility in tex itself.
I can't hear your tone of voice on this comment. Is there, perhaps,
a hint of sarcasm.
Knuth provide the hook to which such a capability could be added.
And this capability was indeed, as you note, added.
pdftex is a monolith. It takes the source file, and gives you PDF
back. You can control it with TeX macros. And that's it. With
TeX, you can define and use specials. And do all sorts of other
things with the dvi file.
(Oh, I forgot. pdftex has configuration files.)
TeX has a flexibility that pdfTeX generating PDF lacks.
For example (see another thread) conversion of dvi to svg.
--
Jonathan
Heiko Oberdiek
> >>>>> Chris Rodgers <rod...@physchem.NOSPAMox.aREMOVEc.uk> (CR) wrote:
>
> >CR> Hi,
> >CR> I have encountered a problem using \textcolor and \marginpar together. The
> >CR> following document illustrates the problems. When processed with latex, I
> >CR> get a DVI which shows the correct colours in xdvik. However, when processed
> >CR> with pdflatex, the PDF file only shows blue text on the first line of the
> >CR> blue section.
>
> >CR> Can anyone suggest a fix for this?
>
> PDFTeX doesn't have a color stack. There is a package pdfcolmk that solves
> the problem at page boundaries, but unfortunately it doesn't help in this
> case.
You are correct.
But it can be fixed, using "q" (gsave) and "Q" (grestore).
Then the color before "q" is restored after "Q". I have identified
\@addmarginpar as location to apply this fix:
\makeatletter
\def\@addmarginpar{\@next\@marbox\@currlist{\@cons\@freelist\@marbox
\@cons\@freelist\@currbox}\@latexbug\@tempcnta\@ne
\if@twocolumn
\if@firstcolumn \@tempcnta\m@ne \fi
\else
\if@mparswitch
\ifodd\c@page \else\@tempcnta\m@ne \fi
\fi
\if@reversemargin \@tempcnta -\@tempcnta \fi
\fi
\ifnum\@tempcnta <\z@ \global\setbox\@marbox\box\@currbox \fi
\@tempdima\@mparbottom
\advance\@tempdima -\@pageht
\advance\@tempdima\ht\@marbox
\ifdim\@tempdima >\z@
\@latex@warning@no@line {Marginpar on page \thepage\space
moved}%
\else
\@tempdima\z@
\fi
\global\@mparbottom\@pageht
\global\advance\@mparbottom\@tempdima
\global\advance\@mparbottom\dp\@marbox
\global\advance\@mparbottom\marginparpush
\advance\@tempdima -\ht\@marbox
\global\setbox \@marbox
\vbox {\vskip \@tempdima
\box \@marbox}%
\global \ht\@marbox \z@
\global \dp\@marbox \z@
\kern -\@pagedp
\nointerlineskip
\hb@xt@\columnwidth
{\ifnum \@tempcnta >\z@
\hskip\columnwidth \hskip\marginparsep
\else
\hskip -\marginparsep \hskip -\marginparwidth
\fi
\pdfliteral{q}%
\rlap{%
\box\@marbox
}%
\pdfliteral{Q}%
\hss
}%
\nointerlineskip
\hbox{\vrule \@height\z@ \@width\z@ \@depth\@pagedp}}
\makeatother
I plan to add this to pdfcolmk.sty.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Heiko Oberdiek
> Robin Fairbairns wrote:
> > Jonathan Fine <jf...@pytex.org> writes:
> >
> >>Then, I'm not a pdftex user. I just expect it to behave in certain
> >>ways, based on my use of TeX.
> >
> >
> > if you experience tex doing colour right, it's very little to do with
> > knuth: it's tom rokicki's colour stack, typically used by david
> > carlisle's latex color.sty
>
> I agree. Knuth provided the \special mechanism and, as he intended,
> others took advantage of it.
>
>
> >>You're right, though, it is something of a basic omission.
> >
> >
> > which is no doubt why don didn't include the facility in tex itself.
>
> I can't hear your tone of voice on this comment. Is there, perhaps,
> a hint of sarcasm.
>
> Knuth provide the hook to which such a capability could be added.
> And this capability was indeed, as you note, added.
The hook is not sufficient at all:
* \special cannot be made invisible for typesetting.
* The interface is not user friendly at all. A color stack
assumes a vertical stream of data to be broken across
pages. But you can have several streams (footnotes,
footnotes inside footnotes, ...).
> pdftex is a monolith. It takes the source file, and gives you PDF
> back. You can control it with TeX macros. And that's it. With
> TeX, you can define and use specials. And do all sorts of other
> things with the dvi file.
pdfTeX gives you PDF *and* DVI. You can define and use
specials in DVI mode and use "specials" translated to PDF format
(\pdfliteral for page streams, \pdfobj and many other to affect
the PDF objects). And do all sorts of other things with the
PDF file. Do you know TeX macros that can combine several
DVI files?
> TeX has a flexibility that pdfTeX generating PDF lacks.
What do you miss?
> For example (see another thread) conversion of dvi to svg.
DVI is a *binary* file format. TeX cannot even read binary files.
How do you want to convert DVI files at TeX macro level?
And if you mean you can put the commands into specials that
are interpreted by other programs than TeX:
* This not a problem for pdfTeX in pdf mode, you can add
comments in page streams, see ppower4.
* You can put data in pdf objects, see pdftosrc, ...
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Jonathan Fine
Heiko Oberdiek wrote:
> Jonathan Fine <jf...@pytex.org> wrote:
<snip>
>>Knuth provide the hook to which such a capability could be added.
>>And this capability was indeed, as you note, added.
>
>
> The hook is not sufficient at all:
> * \special cannot be made invisible for typesetting.
> * The interface is not user friendly at all. A color stack
> assumes a vertical stream of data to be broken across
> pages. But you can have several streams (footnotes,
> footnotes inside footnotes, ...).
Coloured output comes from TeX, macros and printer driver
working together.
It is not clear to me that the problem is the TeX.
Please post a minimal example.
--
Jonathan
Jonathan Fine
>>>>>>Chris Rodgers <rod...@physchem.NOSPAMox.aREMOVEc.uk> (CR) wrote:
>>>>>
>
>>>>PDFTeX doesn't have a color stack. There is a package pdfcolmk that solves
>>>>the problem at page boundaries, but unfortunately it doesn't help in this
>>>>case. I don't think you can do much more than manually putting additional
>>>>\color{blue} declarations at the place where it goes wrong. UGLY!!!
>>>>If you don't want to exactly find out where the page break is, a
>>>>\vadjust{\color{blue}} will be easier (e.g. after the \marginpar). Most of
>>>>the time it will have the proper effect.
>>>
>
>>CR> This seems a rather basic omission. Can I assume that it is already on
>>CR> someone's TODO list, or should I report this somewhere?
>
>
> It has been known for several years.
Chris Rodgers posted a minimal example that showed that PDF output
from pdftex had colour different from the dvi output.
His example has text in one colour, and a margin note in another.
I read in the PDF TeX manual, dated October 8, 2004:
===
When pdf output is not selected, pdfTEX produces normal dvi output,
otherwise it generates pdf output that looks identical to the dvi
output.
==
This statement clearly has to be taken with a pinch of salt.
Here's the URL:
http://www.tug.org/applications/pdftex/pdftex-s.pdf
--
Jonathan
Taco Hoekwater
>
> Chris Rodgers posted a minimal example that showed that PDF output
> from pdftex had colour different from the dvi output.
>
> His example has text in one colour, and a margin note in another.
>
>
> I read in the PDF TeX manual, dated October 8, 2004:
> ===
> When pdf output is not selected, pdfTEX produces normal dvi output,
> otherwise it generates pdf output that looks identical to the dvi
> output.
> ==
>
> This statement clearly has to be taken with a pinch of salt.
The appearance of color presence (or any kind of \special really) in
the dvi file is the result of driver-specific postprocessing, so the
statement is false, but nor in the way you expect it to be. The pdf
file should contain only black markings, with gaps where images were
referenced.
Taco
Jonathan Fine
"Taco Hoekwater" <ta...@elvenkind.com> wrote in message
news:42a7f9fa$0$49087$e4fe...@news.xs4all.nl...
Ah, Henry Ford.
"You can have any color you want ... as long as it is black."
--
Jonathan
Robin Fairbairns
you were surely present at the uk tug meeting in (iirc) warwick where
david carlisle explained the many problems that \special for colour
introduces. was your post merely a challenge to heiko and me, or had
you really forgotten what david said?
many macros (but admittedly only those designed for careful page
positioning) will examine what's gone immediately before them before
inserting skips, etc.
the first example that came up when i searched the latex bugs database
was:
http://www.latex-project.org/cgi-bin/ltxbugs2html?pr=graphics/3356
which is a classic type example -- it actually shows tex itself
misbehaving in the presence of a \special -- that \special alters the
spacing inside a \vtop is not something any ordinary mortal might
reasonably expect. (it is, i am assured, clear if you read the code
of tex.)
that particular problem is susceptible of a work-around, though it's
hard to imagine an automatic one that doesn't itself provoke problems
elsewhere. there are many similar ones that aren't so simply
workable-around.
Heiko Oberdiek
\hbox{%
\hsize=20mm
\vtop{Hello}
\vtop{World}
\vtop{
\special{}
World
}
}%
\bye
The inserted \special influences the typesetting.
In many, but not all situations it can be circumvented.
However, it causes a lot of painful work.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Robin Fairbairns
>Chris Rodgers posted a minimal example that showed that PDF output
>from pdftex had colour different from the dvi output.
>
>His example has text in one colour, and a margin note in another.
>
>I read in the PDF TeX manual, dated October 8, 2004:
>===
>When pdf output is not selected, pdfTEX produces normal dvi output,
>otherwise it generates pdf output that looks identical to the dvi
>output.
>==
>
>This statement clearly has to be taken with a pinch of salt.
>
>Here's the URL:
> http://www.tug.org/applications/pdftex/pdftex-s.pdf
but you're not running the same macros when working with \pdfoutput=1,
so the (admittedly injudicious) remark in the pdftex manual is not
applicable in this case.
if you _were_ running the same macros, you would get errors all over
the place in one or the other mode, and most sensible people would not
expect "correct" output. hence my feeling that the manual remark is
injudicious.
Piet van Oostrum
>HO> You are correct.
>HO> But it can be fixed, using "q" (gsave) and "Q" (grestore).
>HO> Then the color before "q" is restored after "Q". I have identified
>HO> \@addmarginpar as location to apply this fix:
Are similar problems to be expected with floats?
David Carlisle
Piet writes
> Are similar problems to be expected with floats?
yes if a float floats in to a coloured region, although in that case I'd
guess the extension package to use marks to maintain some colour state
would work round things. marginpar breaks up and rebuilds the page in
more entertaining ways which makes that hard, and of course split
footnotes defeat even dvips's colour stack, as what's really needed is a
separate stack of colour contexts for each text flow that may be page
broken (which in latex is just the main flow and footnotes). Or of
course some rather more helpful support from the underlying typesetter,
associating colour as a property of the fonts (and rules) rather than
just recording state changes at specific points.
David
Jonathan Fine
> Jonathan Fine <jf...@pytex.org> writes:
<snip>
>>It is not clear to me that the problem is the TeX.
>>
>>Please post a minimal example.
>
>
> you were surely present at the uk tug meeting in (iirc) warwick where
> david carlisle explained the many problems that \special for colour
> introduces. was your post merely a challenge to heiko and me, or had
> you really forgotten what david said?
Indeed I recall at being at such a meeting. We were all rather
younger then.
And indeed David explained the difficulties \emph{from within
LaTeX} that using \special for colour introduces. (My emphasis.)
> many macros (but admittedly only those designed for careful page
> positioning) will examine what's gone immediately before them before
> inserting skips, etc.
Storing things on the current page is one way to record state.
> the first example that came up when i searched the latex bugs database
> was:
>
> http://www.latex-project.org/cgi-bin/ltxbugs2html?pr=graphics/3356
>
> which is a classic type example
Thank you for this. However, I think it is some way from minimal.
Perhaps we can revisit it when we have dealt with Heiko's example.
> -- it actually shows tex itself
> misbehaving in the presence of a \special -- that \special alters the
> spacing inside a \vtop is not something any ordinary mortal might
> reasonably expect. (it is, i am assured, clear if you read the code
> of tex.)
Please suggest an alternative behaviour for TeX.
BTW, \write will behave in exactly the same way.
> that particular problem is susceptible of a work-around, though it's
> hard to imagine an automatic one that doesn't itself provoke problems
> elsewhere. there are many similar ones that aren't so simply
> workable-around.
I'd prefer a more neutral statement. One that makes fewer assumptions.
How about:
That particular problem can be solved.
And then how about:
There are many similar ones that can also be solved,
with more effort.
--
Jonathan
Jonathan Fine
> Jonathan Fine <jf...@pytex.org> wrote:
<snip>
>>Please post a minimal example.
>
>
> \hbox{%
> \hsize=20mm
> \vtop{Hello}
> \vtop{World}
> \vtop{
> \special{}
> World
> }
> }%
>
> \bye
Thank you for this.
> The inserted \special influences the typesetting.
Yes, of course it does. It's a 'whatsit'.
Besides \special, \mark and \write are whatsits.
And also \openout and \closeout.
I assume that the output you want is given by
\vtop{
\leavevmode\special{}World
}
Is this correct?
Assuming you say YES, TeX can generate the output you
want from your example.
> In many, but not all situations it can be circumvented.
> However, it causes a lot of painful work.
Is this the problem?
That you would like it to be easier to issue sequences
of commands such as:
\leavemdode\special{}World
--
Jonathan
Jonathan Fine
<snip>
> Or of
> course some rather more helpful support from the underlying typesetter,
> associating colour as a property of the fonts (and rules) rather than
> just recording state changes at specific points.
As you may have noticed already, David, I've started a thread on this
very topic.
Robin Fairbairns has posted to it, and mentioned a talk you gave
on this very topic.
I'd be pleased if you joined in on this thread.
<http://groups-beta.google.com/group/comp.text.tex/msg/6e82d016d7c4eb05?hl=en>
--
Jonathan
David Kastrup
> Robin Fairbairns wrote:
>
>> -- it actually shows tex itself
>> misbehaving in the presence of a \special -- that \special alters the
>> spacing inside a \vtop is not something any ordinary mortal might
>> reasonably expect. (it is, i am assured, clear if you read the code
>> of tex.)
>
> Please suggest an alternative behaviour for TeX.
Specials are described in the TeXbook as something which should not
change TeX's position DVI interpretation (in order to get reproducible
results when the special is not supported by some DVI drivers).
In a similar manner, TeX's decision where to fix the baseline of a box
should not depend on whatsits or marks. At the top of a page, TeX is
in a somewhat special mode until it encounters the first box or rule.
Only then will it fix the \topskip.
A similar special mode would be desirable for the start of vertical
boxes in general (there are a few decisions that get made by looking
whether the current vertical list is completely empty. In almost
every case, the results would be more desirable if whatsit and mark
nodes were not deemed relevant here). The problem is some what
exacerbated by \lastbox possibly removing the first such node from the
list. However, the \lastbox operation already has to retraverse the
respective list: while it does that it could simultanously
establish/reestablish the "still before first box or rule" state.
> BTW, \write will behave in exactly the same way.
Yes, this is also a real nuisance.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
UKTUG FAQ: <URL:http://www.tex.ac.uk/cgi-bin/texfaq2html>
David Kastrup
> Besides \special, \mark and \write are whatsits.
While \mark s behave for all practical purposes like whatsits, they
are not really whatsits. Don't ask me why.
Robin Fairbairns
you don't understand the concept of the minimal example, do you? you
asked for a minimal example, and heiko gave you one. of course, the
work-around for the minimal example of the problem is simple.
try installing that work-around in the package that started the
discussion (the latex color package) and it's probably safe to
guarantee that it will cause problems elsewhere.
no-one is blaming tex for not dealing with colour properly (it just
wasn't an issue when tex was designed, and don has declared that it's
not going to change).
but to claim that there is no problem, as you seem to, is just plain
silly.
Jonathan Fine
> Jonathan Fine <jf...@pytex.org> writes:
>
>
>>Besides \special, \mark and \write are whatsits.
>
>
> While \mark s behave for all practical purposes like whatsits, they
> are not really whatsits. Don't ask me why.
Thank you for this clarification. Like yourself, I don't know why.
--
Jonathan
Heiko Oberdiek
> Heiko Oberdiek wrote:
> > Jonathan Fine <jf...@pytex.org> wrote:
>
> <snip>
>
> >>Please post a minimal example.
> >
> >
> > \hbox{%
> > \hsize=20mm
> > \vtop{Hello}
> > \vtop{World}
> > \vtop{
> > \special{}
> > World
> > }
> > }%
> >
> > \bye
>
> Thank you for this.
>
> > The inserted \special influences the typesetting.
>
> Yes, of course it does. It's a 'whatsit'.
>
> Besides \special, \mark and \write are whatsits.
> And also \openout and \closeout.
>
>
> I assume that the output you want is given by
> \vtop{
> \leavevmode\special{}World
> }
>
> Is this correct?
This is the problem, a solution depends on the following contents
in the box, e.g. replace "World" by "\noindent World". Then
the parindent get lost.
> Assuming you say YES, TeX can generate the output you
> want from your example.
Some generalisation:
\long\def\vtopbox#1{%
\vtop{#1}%
}
\long\def\vtopboxspecial#1{%
\vtop{%
\special{}% insufficient implementation
#1%
}%
}
Now prove, that a macro definition of \vtopboxspecial can
be given so that the generated \vtop behaves in the *same*
way as the \vtop by \vtopbox in *all* situations (except
\showbox, \showlists).
And this is just one location where a \special can occur.
This is the probem, you have to consider many, many cases,
many of them are very complicate to fix. And I think, it is not
possible to fix *all* cases for *all* situations. (But I don't
want to prove it.)
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Jonathan Fine
> Jonathan Fine <jf...@pytex.org> writes:
<snip>
> you don't understand the concept of the minimal example, do you? you
> asked for a minimal example, and heiko gave you one. of course, the
> work-around for the minimal example of the problem is simple.
Why do you call what I wrote a 'work-around'?
Heiko, in his example, wants certain output.
I have explained how to get the output I think he wants.
And I've asked him to confirm this.
To my way of thinking, Heiko has posed a problem.
And I have provided a solution.
> try installing that work-around in the package that started the
> discussion (the latex color package) and it's probably safe to
> guarantee that it will cause problems elsewhere.
The problems that clearly exist arise out of four factors -
a) The input document
b) The macro package
c) TeX the program
d) The printer driver
My question (see subject) is this:
> Is TeX's \special hook adequate for color
I asked it because Heiko said it was not.
You have just said -- I paraphrase as carefully as I can --
If this solution (or work-around) is installed in the
latex color package, then it is very likely to cause
problems elsewhere
I'm not convinced of this, but to continue the discussion
let's assume you are correct.
You are saying, it seems to me, that the solution to the
problem is likely to be inconsistent with the LaTeX colour
package.
> no-one is blaming tex for not dealing with colour properly (it just
> wasn't an issue when tex was designed, and don has declared that it's
> not going to change).
Whether or not TeX is consistent with proper treatment of colour is
precisely the issue that we are discussing.
Perhaps, as I have said, the problem is due to the input document,
the macro package, or the printer driver, or some combination of
all three.
> but to claim that there is no problem, as you seem to, is just plain
> silly.
I am not claiming that there is no problem. Just that it is not
established TeX is inconsistent with its solution.
I believe that the best way to make progress in this discussion is
in the careful examination of well-crafted examples.
Examples have a way of testing the truth of generalisations.
--
Jonathan
Jonathan Fine
<snip>
> Specials are described in the TeXbook as something which should not
> change TeX's position DVI interpretation (in order to get reproducible
> results when the special is not supported by some DVI drivers).
Indeed. What Don Knuth wrote was (page 229):
> Software programs that convert |dvi| files to printed or
> displayed output should be able to fail gracefully when they don't
> recognize your special keywords. Thus, |\special| operations should
> never do anything that changes the current position.
> In a similar manner, TeX's decision where to fix the baseline of a box
> should not depend on whatsits or marks.
I don't agree. Each whatsit has a location in the box it is part of.
Just as each character, rule, kern and glue has a location.
This location is important, for example, when the box is split.
This way, index entries (a particular use of \write whatsits) are
able to \write the correct page number.
I said 'I don't agree'. More exactly, you've not said enough to
convince me that such a change is a good idea.
And even if an excellent idea (which it may be), it is not
present any TeX extension. And so the subject of the thread:
> Is TeX's \special hook adequate for color
will still be of practical importance.
What you are saying, I think, is that you would like to be able
to place whatsits on the page, without such placement affecting
TeX's typesetting decisions.
<examples of how misplaced specials interefere snipped>
This is, I think, a reasonable requirement.
Please confirm that I have understood you correctly.
>>BTW, \write will behave in exactly the same way.
>
> Yes, this is also a real nuisance.
Please could you give us some real-world examples of this.
--
Jonathan
Robin Fairbairns
>> david carlisle explained the many problems that \special for colour
>> introduces. was your post merely a challenge to heiko and me, or had
>> you really forgotten what david said?
>
>Indeed I recall at being at such a meeting. We were all rather
>younger then.
>
>And indeed David explained the difficulties \emph{from within
>LaTeX} that using \special for colour introduces. (My emphasis.)
he explained the sorts of places where using \special for colour
causes problems. those places (as evidenced by heiko's real minimal
example, which is little more than the bug report, rendered minimal)
are equally problematic in plain tex.
Heiko Oberdiek
> David Kastrup wrote:
>
> <snip>
>
> > Specials are described in the TeXbook as something which should not
> > change TeX's position DVI interpretation (in order to get reproducible
> > results when the special is not supported by some DVI drivers).
>
> Indeed. What Don Knuth wrote was (page 229):
> > Software programs that convert |dvi| files to printed or
> > displayed output should be able to fail gracefully when they don't
> > recognize your special keywords. Thus, |\special| operations should
> > never do anything that changes the current position.
Thus you have found another limitation of \special:
scaling and rotating cannot be implemented, because
they must change the current coordinate system.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Jonathan Fine
> Jonathan Fine <jf...@pytex.org> wrote:
<snip>
>>I assume that the output you want is given by
>> \vtop{
>> \leavevmode\special{}World
>> }
>>
>>Is this correct?
>
>
> This is the problem, a solution depends on the following contents
> in the box, e.g. replace "World" by "\noindent World". Then
> the parindent get lost.
A nice example. Let's assume that the \special changes colour.
And that we want 'World' to be after the \special in the dvi file.
And that the user input is:
\noindent World
Clearly, either of the following will do the job
\noindent \special{}World
\noindent \leavevmode\special{}World
but not, as you remark
\leavevode\special{}\noindent World
Here, we are assuming that \noindent has the usual TeX semantics.
So what we have here is, in my opinion, a sort of text
transformation problem.
Input: World
Output: \leavevmode\special{}World
Input: \noindent World
Output: \noindent \special{}World
<interesting problem snipped due to lack of time to answer>
> This is the probem, you have to consider many, many cases,
> many of them are very complicate to fix. And I think, it is not
> possible to fix *all* cases for *all* situations. (But I don't
> want to prove it.)
Based upon comments of David Kastrup, I have formulated the
following requirement:
> What you are saying, I think, is that you would like to be able
> to place whatsits on the page, without such placement affecting
> TeX's typesetting decisions.
Or to put it another way - that clobbering \special like so:
\def\special#1{}
should not change the placement of characters and rules in the
output of TeX.
--
Jonathan
Heiko Oberdiek
> Robin Fairbairns wrote:
> > Jonathan Fine <jf...@pytex.org> writes:
>
> <snip>
>
> > you don't understand the concept of the minimal example, do you? you
> > asked for a minimal example, and heiko gave you one. of course, the
> > work-around for the minimal example of the problem is simple.
>
> Why do you call what I wrote a 'work-around'?
>
> Heiko, in his example, wants certain output.
No, I have shown where the insertion of \special causes
problems. See my answer.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Robin Fairbairns
>Robin Fairbairns wrote:
>> Jonathan Fine <jf...@pytex.org> writes:
>
><snip>
>
>> you don't understand the concept of the minimal example, do you? you
>> asked for a minimal example, and heiko gave you one. of course, the
>> work-around for the minimal example of the problem is simple.
>
>Why do you call what I wrote a 'work-around'?
because it's working around an established problem in tex.
>Heiko, in his example, wants certain output.
>I have explained how to get the output I think he wants.
>And I've asked him to confirm this.
>
>To my way of thinking, Heiko has posed a problem.
no he hasn't. he responded to you asking for an example of how
\special causes a problem.
>And I have provided a solution.
no; you've demonstrated that _this_ instance of the problem can be
avoided, albeit not in a fashion that actually helps in the original
issue.
>[lots snipped]
Jonathan Fine
> Jonathan Fine <jf...@pytex.org> writes:
>>Why do you call what I wrote a 'work-around'?
>
> because it's working around an established problem in tex.
If you had said:
An established problem in the combination of TeX the
program, LaTeX the macro package, and dvips the
printer driver
I would have agreed with you.
Sometimes, by 'tex', people mean the whole system.
And not just TeX the program.
I'm not convinced that there is a problem of this nature
in TeX the program.
TeX the system is a means of going from marked-up
text to printed pages (or PDF, or PS).
You say there is a problem. This means you cannot get the
desired output from the given input.
The way to persuade me it can't be done is to give me an
example of something that can't be done.
Please give an example of
A) Marked up text
B) Desired output
that cannot be achieved by using TeX the program as the
typesetting component.
--
Jonathan
Jonathan Fine
David, as I recall, spoke from the perspective of LateX.
I agree that plain has no advantages over LaTeX in this respect.
--
Jonathan
David Kastrup
> David Kastrup wrote:
>
> <snip>
>
>> Specials are described in the TeXbook as something which should not
>> change TeX's position DVI interpretation (in order to get reproducible
>> results when the special is not supported by some DVI drivers).
>
> Indeed. What Don Knuth wrote was (page 229):
> > Software programs that convert |dvi| files to printed or
> > displayed output should be able to fail gracefully when they don't
> > recognize your special keywords. Thus, |\special| operations should
> > never do anything that changes the current position.
>
>
>> In a similar manner, TeX's decision where to fix the baseline of a box
>> should not depend on whatsits or marks.
>
> I don't agree. Each whatsit has a location in the box it is part
> of. Just as each character, rule, kern and glue has a location.
Well, marks and writes don't really have a position on the page. They
have a position in the respective sequence of the list.
> This location is important, for example, when the box is split.
Uh, no. Their position within the respective list decides on what
side of the split they end up, but they are not connected with any
page position.
> This way, index entries (a particular use of \write whatsits) are
> able to \write the correct page number.
>
> I said 'I don't agree'. More exactly, you've not said enough to
> convince me that such a change is a good idea.
>
> And even if an excellent idea (which it may be), it is not
> present any TeX extension. And so the subject of the thread:
> > Is TeX's \special hook adequate for color
> will still be of practical importance.
Sure, one would need a new variable, say \whatsitneutrality, that
would default to 0.
> What you are saying, I think, is that you would like to be able to
> place whatsits on the page, without such placement affecting TeX's
> typesetting decisions.
>
> <examples of how misplaced specials interefere snipped>
>
> This is, I think, a reasonable requirement.
>
> Please confirm that I have understood you correctly.
Yes.
>>>BTW, \write will behave in exactly the same way.
>> Yes, this is also a real nuisance.
>
> Please could you give us some real-world examples of this.
There was stuff of the kind
\marginpar{\label{xxx}...
that lead to vertical misplacements.
Robin Fairbairns
>Robin Fairbairns wrote:
>> Jonathan Fine <jf...@pytex.org> writes:
>>>Why do you call what I wrote a 'work-around'?
>>
>> because it's working around an established problem in tex.
>
>If you had said:
> An established problem in the combination of TeX the
> program, LaTeX the macro package, and dvips the
> printer driver
>I would have agreed with you.
oh do stop being silly. this whole thread is about the adequacy of
\special for dealing with colour. that problems are discussed in
terms of the (la)tex colour package is neither here nor there -- any
package using \special, or indeed any other wotsit, will encounter the
same problems.
>[rest snipped unread]
David Kastrup
> Jonathan Fine <jf...@pytex.org> writes:
>>Robin Fairbairns wrote:
>>> Jonathan Fine <jf...@pytex.org> writes:
>>>>Why do you call what I wrote a 'work-around'?
>>>
>>> because it's working around an established problem in tex.
>>
>>If you had said:
>> An established problem in the combination of TeX the
>> program, LaTeX the macro package, and dvips the
>> printer driver
>>I would have agreed with you.
>
> oh do stop being silly.
31: "Can you bind the chains of the Plei'ades, or loose the cords of Orion?
32: Can you lead forth the Maz'zaroth in their season, or can you guide the Bear with its children?
33: Do you know the ordinances of the heavens? Can you establish their rule on the earth?
34: "Can you lift up your voice to the clouds, that a flood of waters may cover you?
35: Can you send forth lightnings, that they may go and say to you, `Here we are'?
David Carlisle
> David, as I recall, spoke from the perspective of LateX.
only because it was (If I recall) a latex themed meeting.
This really is the most bizarre thread. The inadequacy of tex's special
handling to implement reasonable color support has been known for 15
probably 20 years. Nothing that's been said in this thread so far couldn't
have been said (and wasn't said) when the first attempts to produce
color specials were produced (for plain as much as latex) in the 80's.
The fact is it's not possible to define a \color{red} command that works
like a font command and just affects the colour of following stuff
without messing up spacing, sometimes. It's possible to get something
that works most of the time, and most of the time when it doesn't work
some small hand correction like adding \leavevmode fixes things, so
the situation is good enough for most purposes, and so people get by,
but only just...
The fact that you can sometimes correct the spacing by adding
\leavevmode doesn't help defining a robust documentable system unless you
can get the macro to figure out when to do this itself.
putting a whatsit on to the main vertical list means you can't remove (or
even inspect) the skips or boxes above that which leads to other spacing
changes. It's possible to avoid this by totally rewriting the entite
macro package never to use the primitive tex vertical mode for
spacing/penalties etc and to keep all such things in token registers so
they can be handled, sorted and only added when "safe" but this is a big
price to pay and makes the new format incompatible with anything that
tries to use any primitive tex spacing or skip command (ie it would be
incompatible with virtualy all currently existing tex code). Even then
you have the problem of split footnotes (or other split insertions)
insertion splits just don't give you back the same information as page
splits, so basically you lose. Again in some perhaps all cases one can
avoid using split insertions by doing the page break calculations by
hand within the macro package and so having direct control over whether
and where to split boxes, but again this is hard and even harder to do
in any way that's half way compatible with any existing code.
and that's just the foreground colour. Background colours (and border
colours) are harder, in general.
David
Jonathan Fine
<snip>
> 31: "Can you bind the chains of the Plei'ades, or loose the cords of Orion?
> 32: Can you lead forth the Maz'zaroth in their season, or can you guide the Bear with its children?
> 33: Do you know the ordinances of the heavens? Can you establish their rule on the earth?
> 34: "Can you lift up your voice to the clouds, that a flood of waters may cover you?
> 35: Can you send forth lightnings, that they may go and say to you, `Here we are'?
Job 38.
Stirring stuff, but possibly off-topic.
--
Jonathan
Jonathan Fine
>>David, as I recall, spoke from the perspective of LateX.
>
> only because it was (If I recall) a latex themed meeting.
Indeed. No criticism was meant nor, I hope, taken.
> This really is the most bizarre thread. The inadequacy of tex's special
> handling to implement reasonable color support has been known for 15
> probably 20 years. Nothing that's been said in this thread so far couldn't
> have been said (and wasn't said) when the first attempts to produce
> color specials were produced (for plain as much as latex) in the 80's.
I almost agree with you.
I find the thread unusual or exceptional rather than 'most bizarre'.
I would say that the 'inadequacy of tex' in color has been widely
believed for well over 10 years. Perhaps longer - I don't know.
And I think that there may be some new idead in this thread.
> The fact is it's not possible to define a \color{red} command that works
> like a font command and just affects the colour of following stuff
> without messing up spacing, sometimes.
Great. There's a requirement in here. You want color commands that
work like font commands. Well said.
Font commands don't mess up spacing, so that's already implied.
I'm going to describe a test case now. I'd like you to tell me
if you think it is possible.
(The rest of your message, I'm snipping. Let's revisit it once
we've made progress with the test case.)
So here's my test case.
INPUT:
An \bf bold \rm and {\it italic\/} font warmup.
Now we have \green Green \black and Black.
This is a {\blue blue} group.
Vertical stuff.
\vskip 1in
\yellow
\vskip - \lastskip
\vskip 1 pc
\red
\hrule
\blue\centerline{\bf Blue \black and bold {\red red}}
\green
\hrule
OUTPUT:
As with plain TeX, once the assignments
\let\black\relax
\let\green\relax
\let\blue\relax
\let\yellow\relax
\let\red\relax
have been made been made ...
... except that the words 'green', 'blue' and 'red' are in
their respective colours, and the rules are respectively
red and green
David, please confirm that this is an example of your
requirements regarding colour.
--
Jonathan
Jonathan Fine
> Jonathan Fine <jf...@pytex.org> writes:
<snip>
>> Each whatsit has a location in the box it is part
>> of. Just as each character, rule, kern and glue has a location.
>
>
> Well, marks and writes don't really have a position on the page. They
> have a position in the respective sequence of the list.
I said 'box' and you said 'page'. A typo perhaps.
Similarly 'location' and 'position'.
Do you agree with me, that when \shipout is applied to a \box,
each character, rule and whatsit gets a position on the page?
This is my point - that whatsits have a location, to the same
degree that characters have a location.
>>This location is important, for example, when the box is split.
>
>
> Uh, no. Their position within the respective list decides on what
> side of the split they end up, but they are not connected with any
> page position.
I agree with you, except for the 'uh, no'.
And the implications of the word 'but'.
>>This way, index entries (a particular use of \write whatsits) are
>>able to \write the correct page number.
>>
>>I said 'I don't agree'. More exactly, you've not said enough to
>>convince me that such a change is a good idea.
>>
>>And even if an excellent idea (which it may be), it is not
>>present any TeX extension. And so the subject of the thread:
>> > Is TeX's \special hook adequate for color
>>will still be of practical importance.
>
>
> Sure, one would need a new variable, say \whatsitneutrality, that
> would default to 0.
Perhaps. Maybe you start a new thread, to discuss this idea.
>>What you are saying, I think, is that you would like to be able to
>>place whatsits on the page, without such placement affecting TeX's
>>typesetting decisions.
>>
>><examples of how misplaced specials interefere snipped>
>>
>>This is, I think, a reasonable requirement.
>>
>>Please confirm that I have understood you correctly.
>
>
> Yes.
Thank you for this.
>>>>BTW, \write will behave in exactly the same way.
>>>
>>> Yes, this is also a real nuisance.
>>
>>Please could you give us some real-world examples of this.
>
>
> There was stuff of the kind
> \marginpar{\label{xxx}...
>
> that lead to vertical misplacements.
Thank you again.
--
Jonathan
Jonathan Fine
<snip>
> this whole thread is about the adequacy of
> \special for dealing with colour.
agreed
> that problems are discussed in
> terms of the (la)tex colour package is neither here nor there -- any
> package using \special, or indeed any other wotsit, will encounter the
> same problems.
I assume by 'package' you mean (macro) front-end to TeX the program.
If so, then I do not agree with you.
I suggest we look at some examples.
I've recently posted one in response to David Carisle's contribution
to this thread.
--
Jonathan
Piet van Oostrum
>RF> he explained the sorts of places where using \special for colour
>RF> causes problems. those places (as evidenced by heiko's real minimal
>RF> example, which is little more than the bug report, rendered minimal)
>RF> are equally problematic in plain tex.
But \specials are all we have now. The colour stack model from dvips solves
the problem in the majority of the cases (but not all). I think it would be
easier if pdftex also has colour specials (push and pop). At least it would
make the dvips and the pdftex models similar. The \special problems are the
same, and they are also the same as we have now with \pdfliteral. So why
don't we have a colour stack in pdftex. It can't be very difficult.
Of course the real solution, as several people have already mentioned here,
is to have the colour as an attribute of glyphs and rules. It wouldn't be
compliant with Knuth's wishes for TeX, but should be no problem as an
extension of pdfetex. But it is a major change.
--
Piet van Oostrum <pi...@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: pi...@vanoostrum.org
David Kastrup
>>>>>> r...@cl.cam.ac.uk (Robin Fairbairns) (RF) wrote:
>
>>RF> he explained the sorts of places where using \special for colour
>>RF> causes problems. those places (as evidenced by heiko's real
>>RF> minimal example, which is little more than the bug report,
>>RF> rendered minimal) are equally problematic in plain tex.
>
> But \specials are all we have now. The colour stack model from dvips
> solves the problem in the majority of the cases (but not all).
It does not solve it at all. It only works under the assumption that
the only colored thing that will ever get split is the main vertical
list.
And that is hog wash. You'd need a separate color stack for each
splittable entity.
bigfoot.sty has to deal with both color switching models, and the
dvips model is much harder to do right. Basically, I have to manually
unwind the color stack of the footnote at the end of the split part in
the footnote, and I have to reconstitute it when the footnote
continues on the next page.
> I think it would be easier if pdftex also has colour specials (push
> and pop). At least it would make the dvips and the pdftex models
> similar. The \special problems are the same, and they are also the
> same as we have now with \pdfliteral. So why don't we have a colour
> stack in pdftex. It can't be very difficult.
Why transfer something that is fundamentally broken in the dvi model
to PDF?
David Carlisle
Great. There's a requirement in here. You want color commands that
work like font commands. Well said.
It was said over a decade ago:
grfguide.tex:
\subsection{Using Colours}
\subsubsection{Using predefined colours}
The syntax for colour changes is designed to mimic font changes.
The basic syntax is:
\begin{decl}
|\color|\arg{name}
\end{decl}
David
David Carlisle
In most formats (latex, plain, context, ..) If I know box 0 has a vbox, I can go
\setbox2=\vsplit0 to 2\baselineskip
=======
\box0
=========
\box2
=========
and the two output boxes will have whatever fonts they had specified
before, font changes won't leak out and the postscript stack in a
postscript printer won't be trashed when this is printed even though the
text has been re-arranged.
For example The complete document might be the following
\setbox0\vbox{\parskip=0pt plus 1fill \it aa\par bb\par\bf dd\par\rm zz}
\setbox2=\vsplit0 to 2\baselineskip
=======
\box0
=========
\box2
=========
\bye
the requirement is to make this work as well for colours.
If your proposed solution involves redefining \vsplit to do some colour
fix up, add
\immediate\write\maxdimen{\vsplit}
to your test file. (Lots of 3rd party code will assume that unexpandable
tex primitives are unexpandable)
David
Piet van Oostrum
>DK> Piet van Oostrum <pi...@cs.uu.nl> writes:
>>>>>>>> r...@cl.cam.ac.uk (Robin Fairbairns) (RF) wrote:
>>>
>RF> he explained the sorts of places where using \special for colour
>RF> causes problems. those places (as evidenced by heiko's real
>RF> minimal example, which is little more than the bug report,
>RF> rendered minimal) are equally problematic in plain tex.
>>>
>>> But \specials are all we have now. The colour stack model from dvips
>>> solves the problem in the majority of the cases (but not all).
>DK> It does not solve it at all. It only works under the assumption that
>DK> the only colored thing that will ever get split is the main vertical
>DK> list.
I think it solves more cases. In general when the insertion is done in a
stack-wise manner. So some galley is interrupted and someting else is
inserted in its entirety, after which the interrupted galley resumes. And
this can be recursively.
In the case of split footnotes you have two split galleys that are merged.
And that can't be handled with a simple stack model.
>DK> And that is hog wash. You'd need a separate color stack for each
>DK> splittable entity.
Only in the merge case, I think. In standard LaTeX are there other cases
where different split galleys are merged?
>DK> bigfoot.sty has to deal with both color switching models, and the
>DK> dvips model is much harder to do right. Basically, I have to manually
>DK> unwind the color stack of the footnote at the end of the split part in
>DK> the footnote, and I have to reconstitute it when the footnote
>DK> continues on the next page.
>>> I think it would be easier if pdftex also has colour specials (push
>>> and pop). At least it would make the dvips and the pdftex models
>>> similar. The \special problems are the same, and they are also the
>>> same as we have now with \pdfliteral. So why don't we have a colour
>>> stack in pdftex. It can't be very difficult.
>DK> Why transfer something that is fundamentally broken in the dvi model
>DK> to PDF?
Because of lack of another solution at hand at the moment?
David Kastrup
>>>>>> David Kastrup <d...@gnu.org> (DK) wrote:
>
>>DK> Piet van Oostrum <pi...@cs.uu.nl> writes:
>>>>>>>>> r...@cl.cam.ac.uk (Robin Fairbairns) (RF) wrote:
>>>>
>>RF> he explained the sorts of places where using \special for colour
>>RF> causes problems. those places (as evidenced by heiko's real
>>RF> minimal example, which is little more than the bug report,
>>RF> rendered minimal) are equally problematic in plain tex.
>>>>
>>>> But \specials are all we have now. The colour stack model from dvips
>>>> solves the problem in the majority of the cases (but not all).
>
>>DK> It does not solve it at all. It only works under the assumption that
>>DK> the only colored thing that will ever get split is the main vertical
>>DK> list.
>
> I think it solves more cases. In general when the insertion is done in a
> stack-wise manner. So some galley is interrupted and someting else is
> inserted in its entirety, after which the interrupted galley resumes. And
> this can be recursively.
Where would be the point in splitting if you are then putting the
split pieces right back together? In that case you can just insert
the material between the split parts right into the list in the first
place.
> In the case of split footnotes you have two split galleys that are
> merged. And that can't be handled with a simple stack model.
>
>>>> I think it would be easier if pdftex also has colour specials
>>>> (push and pop). At least it would make the dvips and the pdftex
>>>> models similar. The \special problems are the same, and they are
>>>> also the same as we have now with \pdfliteral. So why don't we
>>>> have a colour stack in pdftex. It can't be very difficult.
>
>>DK> Why transfer something that is fundamentally broken in the dvi
>>DK> model to PDF?
>
> Because of lack of another solution at hand at the moment?
A "solution" that helps in few cases (where pdfcolmk does the trick
about equally well) and fails much more fundamentally in others?
Come off it. pdfcolmk uses simple marks to record colors at the point
of a split, and the same solution would easily apply to footnotes.
Yes, it means that one has to tamper with the output routine in order
to do the additional bookkeeping. But a _working_ solution has to do
that anyway. Even if we _had_ multiple color stacks maintained by
PDFTeX and/or dvips/GhostScript, we would need to insert the
information just when to switch to a insertion-specific stack and
back.
And that would be the proper way to do it. It requires extending both
dvips _and_ PDFTeX.
Now if you don't want to do that, the way to achieve _consistency_ is
by dumbing down the level of color support in DVI mode: just don't use
the color stack, but pop off the previous color whenever using a new
one.
That gives you consistency immediately from the LaTeX level, and
starting from that consistency, you can extend pdfcolmk to keep track
of colors also in footnotes and possibly other insertions.
Robin Fairbairns
if the problem would be solved (apart from the trivial matter of macro
programming... ;-) by introducing multiple colour stacks, now would be
a good time to investigate that. personally, i can't see any other
way forward, if we assume that the colour attribute isn't a rational
(immediate) hope in any current tex successor.
mind you, it does create difficulties in following the "no differences
from dvi output" statement, thus laying us all open to yet another
stupid thread some time in the future about this same topic.
Piet van Oostrum
>DK> Where would be the point in splitting if you are then putting the
>DK> split pieces right back together? In that case you can just insert
>DK> the material between the split parts right into the list in the first
>DK> place.
This is the case that is most common. E.g. headers, footers, floats,
marginpars and (unbroken) footnotes into the main list.
>DK> A "solution" that helps in few cases (where pdfcolmk does the trick
>DK> about equally well) and fails much more fundamentally in others?
I understood that pdfcolmk can't do the split footnotes either. Or am I
wrong?
>DK> Come off it. pdfcolmk uses simple marks to record colors at the point
>DK> of a split, and the same solution would easily apply to footnotes.
>DK> Yes, it means that one has to tamper with the output routine in order
>DK> to do the additional bookkeeping. But a _working_ solution has to do
>DK> that anyway. Even if we _had_ multiple color stacks maintained by
>DK> PDFTeX and/or dvips/GhostScript, we would need to insert the
>DK> information just when to switch to a insertion-specific stack and
>DK> back.
Or have a special for saving the current color into a `variable' and
restoring it from that variable. Which could be considered a 1-place deep
stack. The variable could be identified by a name or number. There would
probably some issues with garbage collecting these variables.
>DK> And that would be the proper way to do it. It requires extending both
>DK> dvips _and_ PDFTeX.
Sure.
>DK> Now if you don't want to do that, the way to achieve _consistency_ is
>DK> by dumbing down the level of color support in DVI mode: just don't use
>DK> the color stack, but pop off the previous color whenever using a new
>DK> one.
But you have to save it somewhere.
David Kastrup
>>>>>> David Kastrup <d...@gnu.org> (DK) wrote:
>
>>DK> Where would be the point in splitting if you are then putting the
>>DK> split pieces right back together? In that case you can just insert
>>DK> the material between the split parts right into the list in the first
>>DK> place.
>
> This is the case that is most common. E.g. headers, footers, floats,
> marginpars and (unbroken) footnotes into the main list.
Well, so who keeps you from switching the color back to the old value
as tracked by LaTeX?
>>DK> A "solution" that helps in few cases (where pdfcolmk does the trick
>>DK> about equally well) and fails much more fundamentally in others?
>
> I understood that pdfcolmk can't do the split footnotes either. Or
> am I wrong?
Just what about "equally well" don't you understand? "equally well",
the last time I looked, was not the same as "better".
>>DK> Come off it. pdfcolmk uses simple marks to record colors at the point
>>DK> of a split, and the same solution would easily apply to footnotes.
>>DK> Yes, it means that one has to tamper with the output routine in order
>>DK> to do the additional bookkeeping. But a _working_ solution has to do
>>DK> that anyway. Even if we _had_ multiple color stacks maintained by
>>DK> PDFTeX and/or dvips/GhostScript, we would need to insert the
>>DK> information just when to switch to a insertion-specific stack and
>>DK> back.
>
> Or have a special for saving the current color into a `variable' and
> restoring it from that variable.
And you are going to achieve that without tampering with the output
routine just how? I mean, do you even attempt to understand what you
are replying to?
>>DK> And that would be the proper way to do it. It requires
>>DK> extending both dvips _and_ PDFTeX.
>
> Sure.
>
>>DK> Now if you don't want to do that, the way to achieve
>>DK> _consistency_ is by dumbing down the level of color support in
>>DK> DVI mode: just don't use the color stack, but pop off the
>>DK> previous color whenever using a new one.
>
> But you have to save it somewhere.
PDF color support saves it in a macro right now. The same would, of
course, work with dvips.
We currently have two basically non-working solutions, one simpler and
one more complicated. You want to get equal results for both cases to
be able to develop a consistent strategy. And you propose turning the
simple non-working solution into the complex non-working solution.
This requires extra work on the PDFTeX binary and yields us consistent
non-working solutions.
I propose if consistent non-working solutions are important to you,
you can easily achieve them by turning the non-working complex
solution into the non-working simple solution. This can easily be
achieved at the macro level alone, by popping the color stack always
before pushing a new value, effectively not using it at all.
David Carlisle
Of course Tom R proposed having multiple stacks (and offered to
implement it in a form that could be used in multiple dvi drivers)
but no one took up the offer...
(see paper in some tug agm, this one I think, I don't have tugboats to
hand...
http://www.tug.org/TUGboat/Contents/contents15-3.html
Tom Rokicki
Advanced `special' support in a dvi driver
David
David Kastrup
Robin needed a reminder that the fundamental forces of nature are not
his to command.
Eric
I looked at this article, but it doesn't include Special colors (DeviceN
color space). I have seen a trick to do it with PS which is also compatible
with the common dvi viewers.
If I remember correctly the \special is tweaked so that it views properly
in OzTeX, which supports color specials. So you can view the DVI with its
spot colors also the PS makes PDFs with DeviceN colors.
An ordinary CMYK special looks like: "color cmyk 1 .5 .6 TeXcolorcmyk". If
you tweak it to: "color cmyk 1 .5 .6 1 (MySpotColor) TeXSpotColor"
then OzTeX is happy, because it only reads from left to right. However
/TeXSpotColor reads all 6 parameters.
This postscript/PDF is separatable by any modern system.
Eric
Piet van Oostrum
>DK> A "solution" that helps in few cases (where pdfcolmk does the trick
>DK> about equally well) and fails much more fundamentally in others?
>>>
>>> I understood that pdfcolmk can't do the split footnotes either. Or
>>> am I wrong?
>DK> Just what about "equally well" don't you understand? "equally well",
>DK> the last time I looked, was not the same as "better".
The "about" leaves some room to go in both directions :=)
>DK> Come off it. pdfcolmk uses simple marks to record colors at the point
>DK> of a split, and the same solution would easily apply to footnotes.
>DK> Yes, it means that one has to tamper with the output routine in order
>DK> to do the additional bookkeeping. But a _working_ solution has to do
>DK> that anyway. Even if we _had_ multiple color stacks maintained by
>DK> PDFTeX and/or dvips/GhostScript, we would need to insert the
>DK> information just when to switch to a insertion-specific stack and
>DK> back.
>>>
>>> Or have a special for saving the current color into a `variable' and
>>> restoring it from that variable.
>DK> And you are going to achieve that without tampering with the output
>DK> routine just how? I mean, do you even attempt to understand what you
>DK> are replying to?
Sure you need support from the output routine. I contrasted 'variables'
with 'stacks'.
>DK> And that would be the proper way to do it. It requires
>DK> extending both dvips _and_ PDFTeX.
>>>
>>> Sure.
>>>
>DK> Now if you don't want to do that, the way to achieve
>DK> _consistency_ is by dumbing down the level of color support in
>DK> DVI mode: just don't use the color stack, but pop off the
>DK> previous color whenever using a new one.
>>>
>>> But you have to save it somewhere.
>DK> PDF color support saves it in a macro right now. The same would, of
>DK> course, work with dvips.
The problem with saving the previous colour (I suppose you mean that) in a
macro is that it is the previous colour at the place where the code is,
whereas with inserts and the like you need the colour at the place in the
output stream. That was the problem in the example that triggered this
discussion (The marginpar).
>DK> I propose if consistent non-working solutions are important to you,
This is not about what is important for me. I thought we were just
discussing the various approaches to solving the colour problem.
David Kastrup
>>>>>> David Kastrup <d...@gnu.org> (DK) wrote:
>
>>DK> PDF color support saves it in a macro right now. The same
>>DK> would, of course, work with dvips.
>
> The problem with saving the previous colour (I suppose you mean
> that) in a macro is that it is the previous colour at the place
> where the code is, whereas with inserts and the like you need the
> colour at the place in the output stream. That was the problem in
> the example that triggered this discussion (The marginpar).
That's what the marks are for. You need them in order to retrieve the
color information at the place in the output stream when combining
separate streams.
Nobody claimed that we can make do without color marks.
Jonathan Fine
This is a statement about the syntax of colour changes.
The requirement is a statement about the semantics of colour changes.
(As you know, syntax is how to write the command, and semantics
is what they do.)
BTW, your mailer seems to be quoting text without giving the author.
--
Jonathan
Jonathan Fine
> In most formats (latex, plain, context, ..) If I know box 0 has a vbox, I can go
>
> \setbox2=\vsplit0 to 2\baselineskip
>
> =======
>
> \box0
>
> =========
>
> \box2
>
> =========
>
> and the two output boxes will have whatever fonts they had specified
> before, font changes won't leak out and the postscript stack in a
> postscript printer won't be trashed when this is printed even though the
> text has been re-arranged.
<example snipped>
> the requirement is to make this work for colours.
Font commands work in this way, as your example notes.
So this requirement is already contained in 'work like fonts'.
This is a hard test case to satisfy.
Another is the \unhbox'ing of paragraph lines.
Few documents, in my opinion, will fully exercise this aspect of a
colour implementation.
> If your proposed solution involves redefining \vsplit to do some colour
> fix up, add
> \immediate\write\maxdimen{\vsplit}
> to your test file. (Lots of 3rd party code will assume that unexpandable
> tex primitives are unexpandable)
I don't know of any code that assumes that \vsplit is unexpandable.
And in any case the subject of the thread is
> Is TeX's \special hook adequate for color
and not
> Does 3rd part code constrain TeX colour capabilities
So I don't accept that as a reasonable requirement (for this thread).
Once we know the limits of TeX the program, we can look at compatibilty
with 3rd party code.
--
Jonathan
Jonathan Fine
> if the problem would be solved (apart from the trivial matter of macro
> programming... ;-) by introducing multiple colour stacks, now would be
> a good time to investigate that. personally, i can't see any other
> way forward, if we assume that the colour attribute isn't a rational
> (immediate) hope in any current tex successor.
I can see another way forward, although not perhaps with LaTeX as the
macro package.
> mind you, it does create difficulties in following the "no differences
> from dvi output" statement, thus laying us all open to yet another
> stupid thread some time in the future about this same topic.
Heiko's example shows that misplaced \special's mess up typesetting.
(This was, of course, already well known.)
One problem, I think, is to get the specials in the right place.
(The other is to deal with splitting, say across pages.)
--
Jonathan
Jonathan Fine
> Jonathan Fine <jf...@pytex.org> writes:
>
>
>>David Kastrup wrote:
>>
>><snip>
>>
>>>31: "Can you bind the chains of the Plei'ades, or loose the cords of Orion?
>>>32: Can you lead forth the Maz'zaroth in their season, or can you guide the Bear with its children?
>>>33: Do you know the ordinances of the heavens? Can you establish their rule on the earth?
>>>34: "Can you lift up your voice to the clouds, that a flood of waters may cover you?
>>>35: Can you send forth lightnings, that they may go and say to you, `Here we are'?
>>
>>Job 38.
>>
>>Stirring stuff, but possibly off-topic.
>
>
> Robin needed a reminder that the fundamental forces of nature are not
> his to command.
Such reminders are usually better not sent, in my opinion, to the whole
newsgroup.
Perhaps here a personal email would have been enough.
--
Jonathan
David Kastrup
> David Kastrup wrote:
>> Jonathan Fine <jf...@pytex.org> writes:
>>
>>>David Kastrup wrote:
>>>
>>><snip>
>>>
>>>>31: "Can you bind the chains of the Plei'ades, or loose the cords of Orion?
>>>>32: Can you lead forth the Maz'zaroth in their season, or can you guide the Bear with its children?
>>>>33: Do you know the ordinances of the heavens? Can you establish their rule on the earth?
>>>>34: "Can you lift up your voice to the clouds, that a flood of waters may cover you?
>>>>35: Can you send forth lightnings, that they may go and say to you, `Here we are'?
>>>
>>>Job 38.
>>>
>>>Stirring stuff, but possibly off-topic.
>
>> Robin needed a reminder that the fundamental forces of nature are
>> not his to command.
>
> Such reminders are usually better not sent, in my opinion, to the
> whole newsgroup.
Which must be why you just sent one. I think that if you are worried
about the ratio of unwelcome off-topic pontification postings in this
group, your most promising prospective attack vector does not involve
me.
Heiko Oberdiek
> Piet van Oostrum <pi...@cs.uu.nl> wrote:
>
> > >>>>> Chris Rodgers <rod...@physchem.NOSPAMox.aREMOVEc.uk> (CR) wrote:
> >
> > >CR> Hi,
> > >CR> I have encountered a problem using \textcolor and \marginpar together. The
> > >CR> following document illustrates the problems. When processed with latex, I
> > >CR> get a DVI which shows the correct colours in xdvik. However, when processed
> > >CR> with pdflatex, the PDF file only shows blue text on the first line of the
> > >CR> blue section.
> >
> > >CR> Can anyone suggest a fix for this?
> >
> > PDFTeX doesn't have a color stack. There is a package pdfcolmk that solves
> > the problem at page boundaries, but unfortunately it doesn't help in this
> > case.
>
> You are correct.
>
> But it can be fixed, using "q" (gsave) and "Q" (grestore).
> Then the color before "q" is restored after "Q". I have identified
> \@addmarginpar as location to apply this fix:
> [...]
The updated version (v0.6) of pdfcolmk is on its way to CTAN.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Chris Rodgers
>
> Yours sincerely
> Heiko <ober...@uni-freiburg.de>
Thank you. I will give this a go soon.
Yours,
Chris.