'old style' quotations
Philipp Lehman
I stumbled across the following thread:
http://groups.google.com/groups?th=c87d5ac70fc67ef3&seekm=bai0ab
24mh8%241%40mulga.cs.mu.OZ.AU
Judging from this thread, I have the following options:
1) Use Omega's \localleftbox
Not really an option since I want a Tex solution.
2) Look at lineno.sty
It seems like this would be the most robust solution, but it will only
work for whole paragraphs, not for individual lines in a paragraph.
Hence this is not an option either.
3) Use an active space character and abuse \discretionary
This is the approach I finally pursued, arriving at the following
hack:
------------------- %< ------------------------
\documentclass[12pt,a4paper]{article}
\makeatletter
\newcommand*{\openquote}{\textquotedblleft}
\newcommand*{\marginquote}{\textquotedblleft}
\newcommand*{\closequote}{\textquotedblright}
% active spaces
\begingroup
\catcode`\~\active
\uccode`\~` \relax
\uppercase{%
\endgroup\gdef~}{%
\discretionary{}{\hbox{\marginquote}}{}%
\nobreak\space}
% active hyphens
\begingroup
\catcode`\~\active
\uccode`\~\the\hyphenchar\font\relax
\uppercase{%
\endgroup\gdef~}{%
\discretionary{\char\hyphenchar\font}
{\hbox{\marginquote}}{}%
\nobreak\space}
\newcommand*{\oldstylequote}{%
\begingroup
% no automatic hyphenation!
\catcode` \active
% explicit hyphens
\catcode\the\hyphenchar\font\active
% manual hyphenation
\def\-{%
\discretionary{\char\hyphenchar\font}
{\hbox{\marginquote}}{}%
\nobreak\space}%
\openquote\@oldstylequote}
\def\@oldstylequote#1{%
#1\closequote
\endgroup}
\makeatother
\frenchspacing
\begin{document}
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed
diam nonummy nibh euismod tincidunt ut laoreet dolore magna
aliquam erat volutpat. Ut wisi enim ad minim veniam.
\oldstylequote{Lorem ipsum dolor sit amet, consectetuer
adipiscing elit, sed diam nonummy nibh euismod tincidunt ut
laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad
minim veniam, quis nostrud exerci tation ullamcorper suscipit
lobortis nisl ut aliquip ex ea commo\-do consequat. Duis autem vel
eum iriure dolor in hendrerit in vulputate velit esse molestie
consequat, vel illum dolore eu feugiat nulla facilisis at vero
qui blandit praesent luptatum facilisi.} Lorem ipsum dolor sit
amet, consectetuer adipiscing elit, sed diam nonummy nibh
euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.
\end{document}
------------------- %< ------------------------
I can put up with the fact that hyphenation needs to be done manually,
but there are still two problems:
1) I put a space after every margin quote. I'd like to be able to
eliminate that as an option.
2) Since there is stretchable space after the margin quote, the quote
margin is slightly ragged. That is, the margin quotes are set flush
left but the first characters after the margin quote don't line up
vertically. This is not really acceptable.
I just can't figure out how to get stretchable active spaces and still
maintain a rigid left quote margin. In an ideal world, I'd have the
third argument of \discretionary insert stretchable space but doesn't
seem to be possible.
Any ideas how to work around this limitation?
--
Sender address blackholed, do not reply by email!
You can still reach me at plehman at gmx dot net.
William F. Adams
I can't help, but I did notice when I ran it in Mac OS X that the first full
line of the quote doesn't get a left quote --- is that a flaw in the macro or a
weird bug in my setup?
Also, you said:
>1) Use Omega's \localleftbox
>Not really an option since I want a Tex solution.
?!? this I don't understand. Omega is TeX, just a Unicode-enabled variant.
Have you looked at Giuseppe's Aleph hybrid?
William
--
William Adams
http://members.aol.com/willadams
Sphinx of black quartz, judge my vow.
David Kastrup
> I can't help, but I did notice when I ran it in Mac OS X that the
> first full line of the quote doesn't get a left quote --- is that a
> flaw in the macro or a weird bug in my setup?
>
> Also, you said:
> >1) Use Omega's \localleftbox
>
> >Not really an option since I want a Tex solution.
>
> ?!? this I don't understand. Omega is TeX, just a Unicode-enabled variant.
>
> Have you looked at Giuseppe's Aleph hybrid?
Ringadingaling, Heureka, Yippie Yeah. Well, almost.
Where do I get PDFAleph? Or at least an Aleph that will cooperate
with the pdfcprot package (I actually don't need PDF output really
urgently)?
I just had a stroke of genius: \localleftbox is _just_ what is needed
for easy automatic generation of per-page line numbers in a number of
circumstances, and even outside of the main text body. Of course, it
has the disadvantage of having exactly the same content on every line,
but as the content may contain a PostScript special, we don't need TeX
to do the counting. We can do that in PostScript, with a counter
reset at bop-hook. Which means that this stuff even is DSC-clean and
won't fail while you page through in a previewer. As long as line
numbers are per-page.
Sure, PostScript hackery is a nuisance, but it beats the kind of
output routine madness lineno.sty has to do hands down.
Now I just need to have pdfcprot working, and I have almost all puzzle
pieces together for line number based critical typesetting of high
quality.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
UKTUG FAQ: <URL:http://www.tex.ac.uk/cgi-bin/texfaq2html>
Giuseppe Bilotta
> Where do I get PDFAleph?
It's up there with Omega 2.0 <g>
> Or at least an Aleph that will cooperate
> with the pdfcprot package (I actually don't need PDF output really
> urgently)?
Ok, what does pdfcprot need?
> I just had a stroke of genius: \localleftbox is _just_ what is needed
> for easy automatic generation of per-page line numbers in a number of
> circumstances, and even outside of the main text body. Of course, it
> has the disadvantage of having exactly the same content on every line,
> but as the content may contain a PostScript special, we don't need TeX
> to do the counting. We can do that in PostScript, with a counter
> reset at bop-hook. Which means that this stuff even is DSC-clean and
> won't fail while you page through in a previewer. As long as line
> numbers are per-page.
One thing I've been thinking about is extending localleftbox to
allow re-typesetting of the box at each output as long as the
box is of fixed width.
--
Giuseppe "Oblomov" Bilotta
Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
(Roger Waters)
David Kastrup
> David Kastrup wrote:
> > Where do I get PDFAleph?
>
> It's up there with Omega 2.0 <g>
Just take care that John does not make you eat your words... Though
you probably would be willing to pay that price.
> > Or at least an Aleph that will cooperate with the pdfcprot package
> > (I actually don't need PDF output really urgently)?
>
> Ok, what does pdfcprot need?
\pdfprotudechars, \lpcode and \rpcode.
Explained probably in
%\bibitem{hanthethanh:thesis}
%H\`{a}n~Th\'{\^{e}} Th\`{a}nh.
%\newblock {\em Micro-typographic extensions to the {\TeX} typesetting system}.
%\newblock Dissertation, Masaryk University Brno: Faculty of Informatics,
% October 2000.
and hopefully in the PDFTeX manual.
> > I just had a stroke of genius: \localleftbox is _just_ what is
> > needed for easy automatic generation of per-page line numbers in a
> > number of circumstances, and even outside of the main text body.
> > Of course, it has the disadvantage of having exactly the same
> > content on every line, but as the content may contain a PostScript
> > special, we don't need TeX to do the counting. We can do that in
> > PostScript, with a counter reset at bop-hook. Which means that
> > this stuff even is DSC-clean and won't fail while you page through
> > in a previewer. As long as line numbers are per-page.
>
> One thing I've been thinking about is extending localleftbox to
> allow re-typesetting of the box at each output as long as the box is
> of fixed width.
Which would not solve the problem of per-page line numbers: at that
point, the page breaks have not yet been chosen. But one could tackle
that problem with some \write-related mechanism. The re-typesetting
of the boxes would have to be done synchronously at \par time. Since
arbitrary code should be executable, it does not really make sense
talking in the context of a box of re-typesetting: instead introduce
an \everyline token register. At the end of a paragraph, if this
token register is non-empty, it gets executed once for every line of
the constituted paragraph (the line gets placed into \box255 and taken
from it afterwards again). Displays and other valign-like material
are not considered.
Something like that.
Giuseppe Bilotta
> Giuseppe Bilotta <bilo...@hotpop.com> writes:
> > David Kastrup wrote:
> > > Where do I get PDFAleph?
> >
> > It's up there with Omega 2.0 <g>
>
> Just take care that John does not make you eat your words... Though
> you probably would be willing to pay that price.
Actually I'm serious. IIRC Omega 2.0 among other things
promises both stability, e-TeX and pdf-TeX features, so it
would factually be a pdfAleph, modulo a name change.
> > > Or at least an Aleph that will cooperate with the pdfcprot package
> > > (I actually don't need PDF output really urgently)?
> >
> > Ok, what does pdfcprot need?
>
> \pdfprotudechars, \lpcode and \rpcode.
>
> Explained probably in
> %\bibitem{hanthethanh:thesis}
> %H\`{a}n~Th\'{\^{e}} Th\`{a}nh.
> %\newblock {\em Micro-typographic extensions to the {\TeX} typesetting system}.
> %\newblock Dissertation, Masaryk University Brno: Faculty of Informatics,
> % October 2000.
>
> and hopefully in the PDFTeX manual.
Ah, it's the protruding stuff.
/me looks into pdftex.ch
Really makes me wonder how easy would it be to plop in the
current Aleph code. After I'm done with sorting out the funcky
OCP/catcodes interaction and the why-do-we-neeed-turkish-
hyphenation-patterns-to-hyphenate-russian bugs, I *might*
decide it's worth a look :)
> > > I just had a stroke of genius: \localleftbox is _just_ what is
> > > needed for easy automatic generation of per-page line numbers in a
> > > number of circumstances, and even outside of the main text body.
> > > Of course, it has the disadvantage of having exactly the same
> > > content on every line, but as the content may contain a PostScript
> > > special, we don't need TeX to do the counting. We can do that in
> > > PostScript, with a counter reset at bop-hook. Which means that
> > > this stuff even is DSC-clean and won't fail while you page through
> > > in a previewer. As long as line numbers are per-page.
> >
> > One thing I've been thinking about is extending localleftbox to
> > allow re-typesetting of the box at each output as long as the box is
> > of fixed width.
>
> Which would not solve the problem of per-page line numbers: at that
> point, the page breaks have not yet been chosen. But one could tackle
> that problem with some \write-related mechanism. The re-typesetting
> of the boxes would have to be done synchronously at \par time. Since
> arbitrary code should be executable, it does not really make sense
> talking in the context of a box of re-typesetting: instead introduce
> an \everyline token register. At the end of a paragraph, if this
> token register is non-empty, it gets executed once for every line of
> the constituted paragraph (the line gets placed into \box255 and taken
> from it afterwards again). Displays and other valign-like material
> are not considered.
>
> Something like that.
Hm.
What exactly makes this currently unfeasible? (i.e. why can't
this currently be done entirely in TeX "user space"?)
David Kastrup
> David Kastrup wrote:
> > Giuseppe Bilotta <bilo...@hotpop.com> writes:
> > > David Kastrup wrote:
> > > > Where do I get PDFAleph?
> > >
> > > It's up there with Omega 2.0 <g>
> >
> > Just take care that John does not make you eat your words... Though
> > you probably would be willing to pay that price.
>
> Actually I'm serious. IIRC Omega 2.0 among other things
> promises both stability, e-TeX and pdf-TeX features, so it
> would factually be a pdfAleph, modulo a name change.
And modulo "other things". Omega 2.0 is decidedly different from
Omega 1.x.
I doubt that stability will be there in a rush, anyway.
> Ah, it's the protruding stuff.
>
> /me looks into pdftex.ch
>
> Really makes me wonder how easy would it be to plop in the
> current Aleph code. After I'm done with sorting out the funcky
> OCP/catcodes interaction and the why-do-we-neeed-turkish-
> hyphenation-patterns-to-hyphenate-russian bugs, I *might*
> decide it's worth a look :)
Would be definitely desirable. Of course, first goal should be to
get a running lambda (Lamed?
<URL:http://www.torahtots.com/alefbet/lamed.htm>) again.
> > > One thing I've been thinking about is extending localleftbox to
> > > allow re-typesetting of the box at each output as long as the box is
> > > of fixed width.
> >
> > Which would not solve the problem of per-page line numbers: at that
> > point, the page breaks have not yet been chosen. But one could tackle
> > that problem with some \write-related mechanism. The re-typesetting
> > of the boxes would have to be done synchronously at \par time. Since
> > arbitrary code should be executable, it does not really make sense
> > talking in the context of a box of re-typesetting: instead introduce
> > an \everyline token register. At the end of a paragraph, if this
> > token register is non-empty, it gets executed once for every line of
> > the constituted paragraph (the line gets placed into \box255 and taken
> > from it afterwards again). Displays and other valign-like material
> > are not considered.
> >
> > Something like that.
>
> Hm.
>
> What exactly makes this currently unfeasible? (i.e. why can't
> this currently be done entirely in TeX "user space"?)
TeX does not let you at the line boxes of a paragraph. Once a
paragraph is contributed to the main vertical list, you can't get
anything back from there. And even if you could: you can't access
the lines separately from interspersed material like display math,
stuff inserted with vadjust, whatsits, marks and other stuff that
strictly blocks disassembly of a list. And if you were thinking
about using \vsplit: forget it. There is no guarantee that a legal
breakpoint occurs between any two lines of a paragraph (for example,
if you are using infinite widowpenalties).
lineno.sty does one heck of a job by offsetting _all_ penalties into
the area below -10000, having a page break at each line, then
assembling stuff together with line numbers and the readjusted
intended penalties.
This is a bunch of fragile madness (does not work with a _lot_ of
other packages), and I can't do this in footnotes, anyhow.
Donald Arseneau
> Giuseppe Bilotta <bilo...@hotpop.com> writes:
> > > that problem with some \write-related mechanism. The re-typesetting
> > > of the boxes would have to be done synchronously at \par time.
> >
> > What exactly makes this currently unfeasible? (i.e. why can't
> > this currently be done entirely in TeX "user space"?)
>
> TeX does not let you at the line boxes of a paragraph. Once a
> paragraph is contributed to the main vertical list, you can't get
> anything back from there. And even if you could: you can't access
> the lines separately from interspersed material like display math,
It is feasible in "user space", but a big hassle.
Material has to be accumulated in a \vbox instead of the main
vertical list (to be \unvboxed to the main list later).
All the possibilities for obstacles in the vertical list have to be
redefined to give sanitized objects on the vertical list (whatzits
wrapped in boxes; special items to tell shifts of hboxes).
varwidth.sty has a v-list sanitizer/processor that handles the usual
material, but is not exhaustive. It starts to get like an implementation
of TeX in TeX macro language.
Donald Arseneau as...@triumf.ca
William F. Adams
>Where do I get PDFAleph? Or at least an Aleph that will cooperate
>with the pdfcprot package (I actually don't need PDF output really
>urgently)?
Well, as _The TeXbook_ says, (hanging punctuation) ``is an easier problem'', so
one simply uses Plain TeX, makes all the punctuation active characters and hack
a protruding hyphen into your (virtual) font. But that's not really practicable
except for one-offs (see my version of Okakura Kakuzo's _The Book of Tea_ in
the TeX Showcase or my portfolio for an example of it).
Isn't there a ``hanging'' (punctuation) environment for LaTeX somewhere? I seem
to recall someone mentioning such once, but perhaps I misunderstood the
reference.
Perhaps the proper way to look at this is to determine if the localleftbox
implementation from Omega could be grafted onto pdftex?
Way cool to hear that character protusion is being considered for Aleph though.
Giuseppe Bilotta
> Giuseppe Bilotta <bilo...@hotpop.com> writes:
> > Ah, it's the protruding stuff.
> >
> > /me looks into pdftex.ch
> >
> > Really makes me wonder how easy would it be to plop in the
> > current Aleph code. After I'm done with sorting out the funcky
> > OCP/catcodes interaction and the why-do-we-neeed-turkish-
> > hyphenation-patterns-to-hyphenate-russian bugs, I *might*
> > decide it's worth a look :)
>
> Would be definitely desirable. Of course, first goal should be to
> get a running lambda (Lamed?
> <URL:http://www.torahtots.com/alefbet/lamed.htm>) again.
If you have Aleph (from TeXLive latest p4, for example), you
should have no problems.
Giuseppe Bilotta
Smells dangeoursly lispish/emacsish. Think I'll implement the
stuff in the core <g>
Philipp Lehman
> 1) Use Omega's \localleftbox
> 2) Look at lineno.sty
> 3) Use an active space character and abuse \discretionary
It seems like there is also:
4) Use an active space character and \vadjust
as exemplified in a post of Donald Arseneau's:
http://groups.google.com/groups?selm=8JUN199813262391
40erich.triumf.ca
In the thread mentioned in my original post he claims that this
approach could be adapted to work for a part of a paragraph, but I
don't see how.
Frank Mittelbach
> Well, as _The TeXbook_ says, (hanging punctuation) ``is an easier
> problem'',
and he was wrong here.
> so one simply uses Plain TeX, makes all the punctuation active
> characters and hack a protruding hyphen into your (virtual) font. But
a) it is not at all just a matter of punctuation but also of other
characters
b) active punctuations can be more than harmful (yes you can do that to
someextend but you have to rewrite an awful lot of code for various
packages you otherwise want to use to get it at least halfway working
> Isn't there a ``hanging'' (punctuation) environment for LaTeX somewhere? I
> seem to recall someone mentioning such once, but perhaps I misunderstood
> the reference.
Peter Wilson did one i think, I did one way back but never published it as
my feeling is that TeX is not up to the job (unless you are prepared for a
lot of manual intervention on top)
pdftex has it already builtin (with a couple of small bugs) --- that is what
i used to TLC2
> Perhaps the proper way to look at this is to determine if the localleftbox
> implementation from Omega could be grafted onto pdftex?
eh? pdftex already can do character protusion (if you ignore that the
implementation has a few bugs and fails in case of kerns at the right side
of the line (eg coming from itlica corrections)
frank
Frank Mittelbach
>> It is feasible in "user space", but a big hassle.
>>
>> Material has to be accumulated in a \vbox instead of the main
>> vertical list (to be \unvboxed to the main list later).
>>
>> All the possibilities for obstacles in the vertical list have to be
>> redefined to give sanitized objects on the vertical list (whatzits
>> wrapped in boxes; special items to tell shifts of hboxes).
>> varwidth.sty has a v-list sanitizer/processor that handles the usual
>> material, but is not exhaustive. It starts to get like an implementation
>> of TeX in TeX macro language.
>
> Smells dangeoursly lispish/emacsish. Think I'll implement the
> stuff in the core <g>
even that is far from trivial (though a very interesting research topic). it
is definitely nothing you "just implement" given that the theoretical
foundation how the interactions between the various levels of processing
and the interaction to the user space level (eg macro language) should look
like is essentially unclear.
omegas OTPs have been one attempt (in a restricted sense) to extend the TeX
model and provide interaction between such different levels, but in my
opinion a completely different and redesigned interaction and process model
needs to be developed to finally get to any longterm solution
frank
William F. Adams
>> Well, as _The TeXbook_ says, (hanging punctuation) ``is an easier
>> problem'',
and Frank replied:
>and he was wrong here.
Do you mean it was wrong of me to note that w/o the context?
>> so one simply uses Plain TeX, makes all the punctuation active
>> characters and hack a protruding hyphen into your (virtual) font. But
>a) it is not at all just a matter of punctuation but also of other
>characters
That's a nicety, but just having hanging punctuation is worthwhile to my mind.
>b) active punctuations can be more than harmful (yes you can do that to
>someextend but you have to rewrite an awful lot of code for various
>packages you otherwise want to use to get it at least halfway working
Right. That's why I noted it was pretty much limited to Plain TeX and one-off
projects, not to production use.
>> Isn't there a ``hanging'' (punctuation) environment for LaTeX somewhere? I
>> seem to recall someone mentioning such once, but perhaps I misunderstood
>> the reference.
>Peter Wilson did one i think, I did one way back but never published it as
>my feeling is that TeX is not up to the job (unless you are prepared for a
>lot of manual intervention on top)
Okay, would the OP let us know if it works out if tried?
>pdftex has it already builtin (with a couple of small bugs) --- that is what
>i used to TLC2
Yep, very nice, optically even margins. Way cool, Gutenberg-like stuff.
>> Perhaps the proper way to look at this is to determine if the localleftbox
>> implementation from Omega could be grafted onto pdftex?
>eh? pdftex already can do character protusion (if you ignore that the
>implementation has a few bugs and fails in case of kerns at the right side
>of the line (eg coming from itlica corrections)
AIUI the \localleftbox thing is different from protruding characters / hanging
punctuation, or is there some low-level implementation aspect I'm not
understanding? In the example the OP provided the desire was for the exact
opposite of protruding characters (intruding quotation marks?).
David Kastrup
> Perhaps the proper way to look at this is to determine if the
> localleftbox implementation from Omega could be grafted onto pdftex?
Probably the easiest way to get at a robust implementation. Who do I
pester best for that wish? If it is feasible, I'd prefer my more
general solution.
Frank Mittelbach
> I'd noted:
>>> Well, as _The TeXbook_ says, (hanging punctuation) ``is an easier
>>> problem'',
>
> and Frank replied:
>>and he was wrong here.
>
> Do you mean it was wrong of me to note that w/o the context?
no. he as in Don Knuth
>>b) active punctuations can be more than harmful (yes you can do that to
>>someextend but you have to rewrite an awful lot of code for various
>>packages you otherwise want to use to get it at least halfway working
>
> Right. That's why I noted it was pretty much limited to Plain TeX and
> one-off projects, not to production use.
>
>>> Perhaps the proper way to look at this is to determine if the
>>> localleftbox implementation from Omega could be grafted onto pdftex?
>
>>eh? pdftex already can do character protusion (if you ignore that the
>>implementation has a few bugs and fails in case of kerns at the right side
>>of the line (eg coming from itlica corrections)
>
> AIUI the \localleftbox thing is different from protruding characters /
> hanging punctuation, or is there some low-level implementation aspect I'm
> not understanding? In the example the OP provided the desire was for the
> exact opposite of protruding characters (intruding quotation marks?).
ah, sorry, my mistake. i didn't checked the earlier postings
frank
Giuseppe Bilotta
> Giuseppe wrote:
> > Smells dangeoursly lispish/emacsish. Think I'll implement the
> > stuff in the core <g>
>
> even that is far from trivial (though a very interesting research topic). it
> is definitely nothing you "just implement" given that the theoretical
> foundation how the interactions between the various levels of processing
> and the interaction to the user space level (eg macro language) should look
> like is essentially unclear.
I know. The requirement is basically that of a line-by-line
paragraph "output" routine :\
> omegas OTPs have been one attempt (in a restricted sense) to extend the TeX
> model and provide interaction between such different levels, but in my
> opinion a completely different and redesigned interaction and process model
> needs to be developed to finally get to any longterm solution
Hanging *punctuation* via OTPs should be more or less a no
brainer, and not blow up existing packages, right?
Giuseppe Bilotta
> will...@aol.com (William F. Adams) writes:
>
> > Perhaps the proper way to look at this is to determine if the
> > localleftbox implementation from Omega could be grafted onto pdftex?
>
> Probably the easiest way to get at a robust implementation. Who do I
> pester best for that wish?
Depends on what timeframe you have in mind for the
implementation.
Dr. Joel M. Hoffman
>> implementation from Omega could be grafted onto pdftex?
>
>eh? pdftex already can do character protusion (if you ignore that the
>implementation has a few bugs and fails in case of kerns at the right side
>of the line (eg coming from itlica corrections)
FWIW, one of the reasons I like plain TeX is that when something
works, it *works*. It doesn't have "a few bugs" or "fail in the case
of...." etc.
Philipp Lehman
>>eh? pdftex already can do character protusion (if you ignore that
>>the implementation has a few bugs and fails in case of kerns at the
>>right side of the line (eg coming from itlica corrections)
>
> FWIW, one of the reasons I like plain TeX is that when something
> works, it *works*. It doesn't have "a few bugs" or "fail in the
> case of...." etc.
Well, by that logic you could also say: "one of the reasons I like my
typewriter is that when it works it just works."
No offense, but keeping the bug count low by effectively declaring an
application dead and frozen is pretty easy. The common approach is to
fix bugs as they are found and as development progresses.
David Kastrup
Oh? So where is that working implementation of using T1-encoded
fonts mixed with other fonts for which no T1 version exists?
Frank Mittelbach
sorry to disagree. there are million of things in plain that do not work
(either at all or only partially) hanging punctuation is one of them.
or take the glorious example of how do you get an italic pound sign.
as for the bugs i mentioned I was talking engine bugs (ie on the level of
TeX (in that case pdftex)) that's a completely different matter and again
TeX is not error proof either --- i own about $1000 worth of cheques by Don
for bugs in TeX.
so i don't see any virtue here. if you restrict yourself to plain plain TeX
then plain plain TeX is what you get (including {\it\$} and the like.
clearly you can declare such things features but then you also can call
them bugs. furthermore for many things it is *nothing goes* which of course
helps with a bug free status
cheers
frank
David Kastrup
Oh? So where is that working implementation of using T1-encoded
fonts mixed with other fonts for which no T1 version exists?
plain TeX has the "advantage" of failing immediately in a large number
of applications. A lot of the complexity in things like LaTeX is
_not_ accepting the plain TeX mantra of "when something works for a
single case, that's good enough. We don't care if it breaks in every
other document; let the authors of those other documents worry about
that."
In plain TeX, you never get a job done for good, just for a
particular document with particular fonts and so on.
If we are taking to the car terminology: Word has a hood that is
welded shut. LaTeX has a hood that can easily be opened and
sometimes you need to open it to get something to run which got stuck
on special roads.
plain TeX cars can't use a hood because otherwise the reins leading
to the motor block would get stuck.
Donald Arseneau
> so i don't see any virtue here. if you restrict yourself to plain plain TeX
> then plain plain TeX is what you get (including {\it\$} and the like.
> clearly you can declare such things features but then you also can call
> them bugs.
Unfortunately, LaTeX also suffers from a milder case of that disease.
Donald Arseneau as...@triumf.ca
Robin Fairbairns
at least it maintains the basic glyph shape, even though it converts
to the oblique font because there's no italic version of the \$ in
ot1.
i would claim, however, that knuth's italic \textsterling is the
_most_ old-fashioned-looking symbol in his typeface ... which claims
to be a c19 ("modern") typeface anyway.
--
Robin (http://www.tex.ac.uk/faq) Fairbairns, Cambridge
Brian Blackmore
Amen Brother!
--
Brian Blackmore
blb8 at po dot cwru dot edu
David Kastrup
Ha, ha, ha. In plain TeX, things break all the time. It is just
easier to figure out why, and how to do a workaround.
William F. Adams
<snip cogent example>
>plain TeX has the "advantage" of failing immediately in a large number
>of applications. A lot of the complexity in things like LaTeX is
>_not_ accepting the plain TeX mantra of "when something works for a
>single case, that's good enough. We don't care if it breaks in every
>other document; let the authors of those other documents worry about
>that."
That's a really good way to put it --- is that formally expressed somewhere? If
not, it should be.
>In plain TeX, you never get a job done for good, just for a
>particular document with particular fonts and so on.
Well, one can get a general class of job done, so long as no new elements (or
characters) are introduced in the future.
>If we are taking to the car terminology: Word has a hood that is
>welded shut. LaTeX has a hood that can easily be opened and
>sometimes you need to open it to get something to run which got stuck
>on special roads.
>plain TeX cars can't use a hood because otherwise the reins leading
>to the motor block would get stuck.
Fortunately, I wasn't drinking anything when I read that last at work...
It's a very good way to put it. To re-work the analogy some so that we're not
mixing metaphors, TeX would be like to a small sports car, w/ the chassis tuned
to a specific track, and shaved tires and missing safety equipment which
preclude it from being street legal, and a funeral clutch requiring a deft,
expert touch to get one moving (though this last can be done by someone other
than the driver).
William
(who is still a plain tex kinda guy (my propeller doesn't spin that fast, and I
mostly do simplistic stuff for which plain tex is suitable to my needs and
means), but has learned to love Latex, esp. at work. I also _really_ miss my
MGB....)
Peter Wilson
"William F. Adams" <will...@aol.com> wrote in message
news:20040515231051...@mb-m20.aol.com...
Take a look at the hanging package; it does do some hanging punctuation
but is better at hanging paragraphs.
Peter W.
--
Email-1: peter dot r dot wilson at boeing dot com
Email-2: pandgwilson at earthlink dot net
The English FAQ is at: http://www.tex.ac.uk/faq
Examples of all symbols:
http://www.ctan.org/tex-archive/info/symbols/comprehensive
PostScript fonts:
http://www.ctan.org/tex-archive/info/Type1fonts/fontinstallationguide.pdf