Hello list, I wish to bring the discussion again on displayed material. Display material is material that conceptually belongs to a paragraphs but typographically breaks it. After the display, the paragraph can continue or not. In ConTeXt, there are many things which should be considered displayed material: formulas, enumerations and other itemgroups, quotations, etc. Every start/stop pair that begins a new paragraph should actually be a displayed area. In ConTeXt, one can achieve such result by using [intentnext=yes] or [indentnext=no] on a case-by-case basis, depending on whether the start/stop pair is supposed to start a new paragraph or not. Of course, this "manual" way to do the thing goes against the general principle that the computer is supposed to do as much of the job as possible, by itself. I therefore wish to urge Hans to implement a new indentnext option, "auto", which should give a behaviour similar to the one shown on this example: === BEGIN displayed.tex === \setupindenting[medium] \definestartstop[display][before=\initdisplay,after=\terminatedisplay,style=italic] \def\initdisplay{\ifvmode\else\endgraf\noindent\fi \bgroup\advance\leftskip2\parindent\advance\rightskip2\parindent\ignorespaces} \def\terminatedisplay{\par\egroup\afterassignment\checkifpar\let\ispar=} \def\checkifpar{\ifx\ispar\par\else\noindent\expandafter\ispar\fi} \starttext The purpouse of this document is to practically show how display material should behave: display material is material that conceptually belongs to a paragraphs but typographically breaks it After the display, the paragraph can continue or not. We now quote Knuth: \startdisplay \input knuth \stopdisplay and continue the paragraph right after. The following quote will instead end the paragraph: \startdisplay \input tufte \stopdisplay This text belongs to a different paragraph: note that it's being indented (differently from the previous snippet). This paragraph has no quotations. Instead, the next paragraph will start with a quotation (display material at the beginning of the paragraph) and have some text after~it. \startdisplay \input knuth \stopdisplay is again a quote from Knuth. Observe that this way the source obeys the \TeX\ convention of empy lines to terminate paragraphs, and that it is not necessary to manually specify the intentnext option for the single cases. \stoptext === END displayed.tex === The paragraph-wise behaviour of \initdisplay and \terminatedisplay+\checkifpar (i.e. excluding the left-/rightskip adaptments, which have only a visual purpouse) should be the behaviour in case indentnext=auto. -- Giuseppe "Oblomov" Bilotta
Since I've earlier agreed with you on this Giuseppe, I'll do so here too. However, there seems to be something weird with this sample file. In the first Knuth entry, the first paragraph is not indented, while in the second (at the end) it is. This is a matter of trivial detail though, and I agree with your basic request. I regularly write documents such as this example. Whatever mechanism we have, I'd want it to automatic, such that DocBook code I might use would just work. As I recall, this was partly addressed with respect to quotes; right? Bruce
Monday, March 10, 2003 Bruce D'Arcus wrote: BDA> Since I've earlier agreed with you on this Giuseppe, I'll do so here BDA> too. BDA> However, there seems to be something weird with this sample file. In BDA> the first Knuth entry, the first paragraph is not indented, while in BDA> the second (at the end) it is. This is a matter of trivial detail BDA> though, and I agree with your basic request. Actually that indent/noindent for the first line of the displayed material was just a personal test to see if I could make it work (so as to distinguish when the displayed material started a new paragraph and when not --when there is indentation on the first line it's because it starts a new paragraph ...) Anyway, I built a "quick and dirty" patch which seems to work for most environments which, I think, require it: itemgroups, definitions, formulas, verbatim. You can put it in your cont-loc between \unprotect ... \protect pairs: === BEGIN PATCH === \startvariables all auto: auto \stopvariables \def\@@stopdefinitie#1% {\par \dostopattributes \endgroup \getvalue{\??dd#1\c!na}% \egroup % temporary hack \doifvalue{\??dd#1\c!springvolgendein}\v!nee\noindentation \doifvalue{\??dd#1\c!springvolgendein}\v!auto\noindent} \def\stopitemgroup {\iftextitems \removeunwantedspaces\space\ignorespaces \else \par \fi \ifnum\itemcolumndepth=\zerocount \dolistreference \fi % beware ! \iffirstlist \else \endgroup \fi % toegevoegd, eerste \som opent groep \ifnum\itemcolumndepth=\itemlevel\relax \stopkolommen \doglobal\newcounter\itemcolumndepth \getitemparameter\itemlevel\c!na \else \ifnum\itemlevel=\plusone \doitembreak\allowbreak % toegevoegd \getitemparameter1\c!na \doif\@@oospringvolgendein\v!nee\noindentation \doif\@@oospringvolgendein\v!auto\noindent \fi \fi \endgroup \doglobal\decrement(\itemlevel,\itemincrement)% \egroup} \def\dostopformula {\doplaceformulanumber \getvalue{\e!stop\getvalue{\??fm\currentformula\c!variant}\e!formule}% \resetlastlinewidth \nonoindentation \doifvalue{\??fm\currentformula\c!springvolgendein}\v!nee\noindentation \doifvalue{\??fm\currentformula\c!springvolgendein}\v!auto\noindent \egroup} \def\dostoptyping#1% {\stopverbatimcolor \stopopelkaar % includes \egroup \getvalue{\??tp#1\c!na}% \doifvalue{\??tp#1\c!springvolgendein}\v!nee\noindentation \doifvalue{\??tp#1\c!springvolgendein}\v!auto\noindent} === END PATCH === Remember to issue the following instructions: \setupformulas[indentnext=auto] \setupitemgroups[indentnext=auto] to make it work. No need to regenerate the formats (you may need to refresh the filename database if you didn't have a cont-loc.tex before that). Hans, can we hope for this to go into the core for the next beta? Note: while I think it should be done for quotations as well, this seems to be a feature "in development" so I won't touch it for now. -- Giuseppe "Oblomov" Bilotta
Just been playing a bit with the magazine style. First, about this:
% This style is used for producing explanationary documents. % Don't misuse it for other purposes, since it may confuse % users. Don't change the title either, since it provides a % way to categorize documents.
Hans, are you saying anyone using this to produce a document ought to keep the title specified in the style (which here seems to be {Zero Issue}? In any case, this is confusing (at least to me)... Also, IIRC, shouldn't the grey border surround the entire page, and extend to the edge? I am getting a thinner border in the shape of an "L," with white space at the page edge. Bruce
At 05:15 PM 3/10/2003 -0500, Bruce D'Arcus wrote:
Just been playing a bit with the magazine style. First, about this:
% This style is used for producing explanationary documents. % Don't misuse it for other purposes, since it may confuse % users. Don't change the title either, since it provides a % way to categorize documents.
Hans, are you saying anyone using this to produce a document ought to keep the title specified in the style (which here seems to be {Zero Issue}? In any case, this is confusing (at least to me)...
no, i mean the main title (* Way) shoul dremain unchanged.
Also, IIRC, shouldn't the grey border surround the entire page, and extend to the edge? I am getting a thinner border in the shape of an "L," with white space at the page edge.
works ok here, puzzled Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
On Tuesday, March 11, 2003, at 03:00 AM, Hans Hagen wrote:
Hans, are you saying anyone using this to produce a document ought to keep the title specified in the style (which here seems to be {Zero Issue}? In any case, this is confusing (at least to me)...
no, i mean the main title (* Way) shoul dremain unchanged.
OK, I understand that. But I'm still unclear of the logic here. I understand the style "is used for producing explanationary documents," but surely not everyone wants to name such documents the same way, and "provides a way to categorize documents" seems more applicable to Pragma than to outside users... I'm not sure how (or if) I might want to use the style, but I could imagine student lab manuals maybe (?). In any case, I appreciate your releasing it, as it's a good learning tool at the very least. Bruce
At 09:11 AM 3/11/2003 -0500, you wrote:
On Tuesday, March 11, 2003, at 03:00 AM, Hans Hagen wrote:
Hans, are you saying anyone using this to produce a document ought to keep the title specified in the style (which here seems to be {Zero Issue}? In any case, this is confusing (at least to me)...
no, i mean the main title (* Way) shoul dremain unchanged.
OK, I understand that. But I'm still unclear of the logic here. I understand the style "is used for producing explanationary documents," but surely not everyone wants to name such documents the same way, and "provides a way to categorize documents" seems more applicable to Pragma than to outside users...
i have no time for that
I'm not sure how (or if) I might want to use the style, but I could imagine student lab manuals maybe (?). In any case, I appreciate your releasing it, as it's a good learning tool at the very least.
sure, i only want to make sure that "This Way" is used for our stuff only; i have no problem with you using the style with a title other than *Way, like LabLog or so Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
On Tuesday, March 11, 2003, at 03:00 AM, Hans Hagen wrote:
Also, IIRC, shouldn't the grey border surround the entire page, and extend to the edge? I am getting a thinner border in the shape of an "L," with white space at the page edge.
works ok here, puzzled
On this, the only thing I changed was to use a different font, since palatino doesn't seem to work from ConTeXt in my new installation. I know this was discussed previously, but don't remember the bottomline point. Shouldn't these fonts that are included with teTeX and TeXLive just work in ConTeXt, without needing any intervention by the user? If yes, whose responsibility is this? Am using Gerben Wierda's OS X installer, but have a feeling this isn't his problem. Or maybe it is? Bruce
"Bruce D'Arcus"
On this, the only thing I changed was to use a different font, since palatino doesn't seem to work from ConTeXt in my new installation.
Same here :(
I know this was discussed previously, but don't remember the bottomline point. Shouldn't these fonts that are included with teTeX and TeXLive just work in ConTeXt, without needing any intervention by the user?
They should...
If yes, whose responsibility is this? Am using Gerben Wierda's OS X installer, but have a feeling this isn't his problem. Or maybe it is?
Yes and no... ConTeXt is looking for fonts with names that are totally unusual compared to the ordinary TeX (LaTeX) System. Most TeX systems (and I guess GW TeX as well) support psnfss, the postscript font system to be used with latex. That means, that you should have fonts named in a cryptic way "pplr8r.tfm" or such. ConTeXt on the other hand looks for fontnames like "8r-uplr8a.tfm". Almost no one has a font named like this on their system. So ConTeXt provides a mapping (remember the command \usetypescript[berry][\defaultencoding]?) that maps from 8r-uplr8a.tfm to uplr8r.tfm. But this will fail on many TeX systems, since there is no such file. (It works on TeXlive7.) ConTeXt should in this case rather map to pplr8r.tfm, which is available on all psnfss systems (i.e. all LaTeX ready systems). I should send Hans a different mapping to go into the distribution. I am still undecided how to name it. Perhaps \usetypescript[psnfss][..]? Or \...[ADOBEkb] as in updmap.cfg? Or adobekb (lowercase)? Patrick
On Tuesday, March 11, 2003, at 09:46 AM, Patrick Gundlach wrote:
Yes and no... ConTeXt is looking for fonts with names that are totally unusual compared to the ordinary TeX (LaTeX) System. Most TeX systems (and I guess GW TeX as well) support psnfss, the postscript font system to be used with latex. That means, that you should have fonts named in a cryptic way "pplr8r.tfm" or such. ConTeXt on the other hand looks for fontnames like "8r-uplr8a.tfm". Almost no one has a font named like this on their system.
This kind of thing is just silly. The above named file is no more clearly named than the psnfss version, so what's the point? Anyway, I vote for your first name option for the mapping file: \usetypescript[psnfss] Make sure you send it to Gerben too, so he can get it in the installer sooner rather than later... Bruce
On Tuesday 11 March 2003 16:10, Bruce D'Arcus wrote:
On Tuesday, March 11, 2003, at 09:46 AM, Patrick Gundlach wrote:
Yes and no... ConTeXt is looking for fonts with names that are totally unusual compared to the ordinary TeX (LaTeX) System. Most TeX systems (and I guess GW TeX as well) support psnfss, the postscript font system to be used with latex. That means, that you should have fonts named in a cryptic way "pplr8r.tfm" or such. ConTeXt on the other hand looks for fontnames like "8r-uplr8a.tfm". Almost no one has a font named like this on their system.
This kind of thing is just silly. The above named file is no more clearly named than the psnfss version, so what's the point?
It is clearer: the first bit gives the encoding and the latter bit is the name of the file containign the glyphs (uplr8a.pfb). OTOH since LaTeX already creates a lot of font-mess, I do agree that there is no need to add more to the trouble already there. I would like to see a few sym-links (does Windows have something like that?) to add a few names to the tree to make sure everything works as planned. Since texfont uses afm2tfm directly (and the tfm files that come with psnfss are hand tuned) I don't think that using texfont blindly is a very good idea. It would be better to use the existing tfm files. The dvips documentation on aft2tfm lists what's been added to the tfm's in the psnfss collection, I cannot recall this right now. Cheers, Maarten Sneep
On Wednesday, March 12, 2003, at 08:04 AM, Maarten Sneep wrote:
That means, that you should have fonts named in a cryptic way "pplr8r.tfm" or such. ConTeXt on the other hand looks for fontnames like "8r-uplr8a.tfm". Almost no one has a font named like this on their system.
This kind of thing is just silly. The above named file is no more clearly named than the psnfss version, so what's the point?
It is clearer: the first bit gives the encoding and the latter bit is the name of the file containign the glyphs (uplr8a.pfb).
The "8r" at the end of the psnfss version also gives the encoding, and I don't really think there's a need to have the precise pfb name in the tfm file name. That's not to say there aren't problems with psnfss, just that in this context those problems aren't important.
Since texfont uses afm2tfm directly (and the tfm files that come with psnfss are hand tuned) I don't think that using texfont blindly is a very good idea. It would be better to use the existing tfm files.
Right. Patrick has a file that maps the ConTeXt names to the pfsnss names, which solves the problem. Bruce
On Wednesday 12 March 2003 14:23, you wrote:
The "8r" at the end of the psnfss version also gives the encoding, and I don't really think there's a need to have the precise pfb name in the tfm file name. That's not to say there aren't problems with psnfss, just that in this context those problems aren't important.
OK.
Since texfont uses afm2tfm directly (and the tfm files that come with psnfss are hand tuned) I don't think that using texfont blindly is a very good idea. It would be better to use the existing tfm files.
Right. Patrick has a file that maps the ConTeXt names to the pfsnss names, which solves the problem.
Although that means you have to adapt the sources of the files you receive to use this intermediate translation file. Although I suspect this is something that could be put in cont-sys.tex (anyone for the exact command?) and make it a system wide local configuration. BTW isn't this something that sould be addressed by using \usetypescript[ber]? (Or did I miss something?) Maarten
Maarten Sneep
Right. Patrick has a file that maps the ConTeXt names to the pfsnss names, which solves the problem.
Although that means you have to adapt the sources of the files you receive to use this intermediate translation file.
You don't need to.
Although I suspect this is something that could be put in cont-sys.tex (anyone for the exact command?) and make it a system wide local configuration.
\usetypescriptfile[tetex] \usetypescript[tetex][someencoding]
BTW isn't this something that sould be addressed by using \usetypescript[ber]? (Or did I miss something?)
Well, in my opinion, the berry typesript is sub-optimal, since it maps to the urw variants that are a) shipped with a few TeX systems only and b) (even worse) the urw variant helvetica (nimbus sans) is of no real use for the german people out there (broken germandbls). Patrick
At 03:05 PM 3/12/2003 +0100, you wrote:
Well, in my opinion, the berry typesript is sub-optimal, since it maps to the urw variants that are a) shipped with a few TeX systems only and b) (even worse) the urw variant helvetica (nimbus sans) is of no real use for the german people out there (broken germandbls).
then, how many people do have the adobe palatino's? concerning the broken german ss: the polish font gurus (you'll meet them at the dante meeting) have made extended versions of those urw fonts, so maybe that will help. [the normal urw also don't have ogoneked glyphs] Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
Hans Hagen
At 03:05 PM 3/12/2003 +0100, you wrote:
Well, in my opinion, the berry typesript is sub-optimal, since it maps to the urw variants that are a) shipped with a few TeX systems only and b) (even worse) the urw variant helvetica (nimbus sans) is of no real use for the german people out there (broken germandbls).
then, how many people do have the adobe palatino's?
None that I know of. But this is IMHO irelevant: the current TeX practice is: 1) TeX macro package (aka LaTeX ;-) asks for "Adobe Helvetica", it gets the font metrics from "phv....tfm". Then, in the map files the users decides whether to use the original adobe fonts or the substitues. 2) TeX macro package (aka ConTeXt ;-) asks for "URW Nimbus Sans" a) on TeXlive (and perhaps any other I don't kown of) it gets the metrics from "uhv....tfm". Then, in the map files the user has no choice; the dvi/pdf driver should take Nimbus Sans. b) on teTeX (+...?) with some special mappings it gets the "phv....tfm" metrics. Then see above at 1). I think it is wrong behaviour to explicitly ask for the substitution and leave the user no choice about which variant (adobe, urw) to use.
concerning the broken german ss: the polish font gurus (you'll meet them at the dante meeting) have made extended versions of those urw fonts, so maybe that will help. [the normal urw also don't have ogoneked glyphs]
Well, concerning the ss: Just install the Adobe Helvetica (free) and that's it (except for patching ConTeXt ;-) Patrick
On Wed, 12 Mar 2003 16:43:40 +0100
Patrick Gundlach
At 03:05 PM 3/12/2003 +0100, you wrote:
Well, in my opinion, the berry typesript is sub-optimal, since it maps to the urw variants that are a) shipped with a few TeX systems only and b) (even worse) the urw variant helvetica (nimbus sans) is of no real use for the german people out there (broken germandbls).
then, how many people do have the adobe palatino's?
None that I know of. But this is IMHO irelevant: the current TeX practice is:
No. No.
1) TeX macro package (aka LaTeX ;-) asks for "Adobe Helvetica", it gets the font metrics from "phv....tfm". Then, in the map files the users decides whether to use the original adobe fonts or the substitues.
the MAP-file is a nice place for the real font selection. How should i tell "normal" users that their font-selection from the document is overwriten since some stupid and wrong decisions have been made in the past.
2) TeX macro package (aka ConTeXt ;-) asks for "URW Nimbus Sans" a) on TeXlive (and perhaps any other I don't kown of) it gets the metrics from "uhv....tfm". Then, in the map files the user has no choice; the dvi/pdf driver should take Nimbus Sans.
that's correct, since *it is* URW...
I think it is wrong behaviour to explicitly ask for the substitution
it's no substitution, it is the font that is ask for. You asks for URW and you get URW. Simple, isn't it? The way the psnfss works is wrong, since one asks for Adobe and gets URW. Please read some threads in the PDFTeX-ML and you can see what confusion this creates.
and leave the user no choice about which variant (adobe, urw) to use.
The choice is made with a new typescript. This is the common procedure when a new font is installed. So, if you have Adobe Palatino then install it as you did for other fonnts too. But, stop! Sorry, there are always entries in the current pdfTeX MAP-file that map your Adobe fonts back to URW variants. So, first you to have edit the MAP-file. No, no you cannot use \loadmapfile since it does not overwrite the wrong psnfss settings. Nice way to fool many users. Many thanks. ;) Thus, include a new typescript in the ConTeXt core that maps to the Adobe names, but please don't support these wrong decisions of the past. Additionally, please don't name the typescript "Adobe....", since it is only Adobe if you have the fonts installed. "psnfss" is a good name: PS-Names-Fooling-Suitable-Setup. For real Adobe fonts everybody should be able to write proper typescripts. Regards, Jens
Jens-Uwe Morawski
Well, in my opinion, the berry typesript is sub-optimal, since it maps to the urw variants that are a) shipped with a few TeX systems only and b) (even worse) the urw variant helvetica (nimbus sans) is of no real use for the german people out there (broken germandbls).
then, how many people do have the adobe palatino's?
None that I know of. But this is IMHO irelevant: the current TeX practice is:
No. No.
Well it is the way psnfss works. That means all LaTeX users do it this way and this is about 99% (wild guess) of all TeX users. So it is current practice.
1) TeX macro package (aka LaTeX ;-) asks for "Adobe Helvetica", it gets the font metrics from "phv....tfm". Then, in the map files the users decides whether to use the original adobe fonts or the substitues.
the MAP-file is a nice place for the real font selection.
I agree with that. (Did you mean it this way?)
How should i tell "normal" users that their font-selection from the document is overwriten since some stupid and wrong decisions have been made in the past.
That is easy: You don't have the real helvetica? Then your dvi processor (or pdfTeX) switches back to a substitution. This is the way every printer works, that don't have the Linotype fonts built in. So what wrong decisions have been made?
2) TeX macro package (aka ConTeXt ;-) asks for "URW Nimbus Sans" a) on TeXlive (and perhaps any other I don't kown of) it gets the metrics from "uhv....tfm". Then, in the map files the user has no choice; the dvi/pdf driver should take Nimbus Sans.
that's correct, since *it is* URW...
I think it is wrong behaviour to explicitly ask for the substitution
it's no substitution, it is the font that is ask for. You asks for URW and you get URW. Simple, isn't it?
Well asking for URW, you get URW; that's clear. But there are three steps involved: 1) the user: he or she requests the typescript [times][..]. What does he want? URW? Or what? IMO I request Times-Roman, and not a substitue. 2) ConTeXt (or other TeX macro packages): When "Helvetica" is requested, it is mapped to uhv..., which is not Helvetica but Nimbus Sans. -> IMO this is wrong behaviour. The user request should be carried through the whole system right to the end, and let the last possible part in the printing process decide "to substitute or not to substitute". 3) The dvi processor: uhv-> get Nimbus Sans. phv-> get Helvetica, when you don't have that (default) get Nimbus Sans. The way with current ConTeXt it is now: I ask for Helvetica and get Nimbus Sans. There is no way around this.
The way the psnfss works is wrong, since one asks for Adobe and gets URW. Please read some threads in the PDFTeX-ML and you can see what confusion this creates.
I did a quick search for Adobe URW, but found nothing. Could you give me some hints?
and leave the user no choice about which variant (adobe, urw) to use.
The choice is made with a new typescript. This is the common procedure when a new font is installed.
I am *not* talking about new fonts! I am talking about some base fonts that are shipped (or better: not shipped) with the TeX system.
So, if you have Adobe Palatino then install it as you did for other fonnts too. But, stop! Sorry, there are always entries in the current pdfTeX MAP-file that map your Adobe fonts back to URW variants. So, first you to have edit the MAP-file.
This is what the mapfile is for!?! Patrick
At 09:31 AM 3/13/2003 +0100, Patrick Gundlach wrote:
the MAP-file is a nice place for the real font selection.
I agree with that. (Did you mean it this way?)
hm, i disagree -) unless you keep your map files with your specific styles / projects
How should i tell "normal" users that their font-selection from the document is overwriten since some stupid and wrong decisions have been made in the past.
That is easy: You don't have the real helvetica? Then your dvi processor (or pdfTeX) switches back to a substitution. This is the way every printer works, that don't have the Linotype fonts built in.
but, subsitutions means ugly results, which means ugly docs, which gives tex a bad reputation
1) the user: he or she requests the typescript [times][..]. What does he want? URW? Or what? IMO I request Times-Roman, and not a substitue.
This is a real tricky area, there are so many times out that if you are not specific and embed them (in graphics, docs, etc) you end up in troubles. We have a few thousand Corel Draw files, mae on a win95 machine long ago, and cannot even open them because the font names changed (distiller 2 accepted the eps, distiller 5 doesn't)
The way with current ConTeXt it is now: I ask for Helvetica and get Nimbus Sans. There is no way around this.
unless you map the names alternatively, which you will do for us; just prepare the lot and we can discuss it in bremen {if tex was less powerfull with math/fonts, live would be so much more easy] Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
At 04:43 PM 3/12/2003 +0100, Patrick Gundlach wrote:
None that I know of. But this is IMHO irelevant: the current TeX practice is:
1) TeX macro package (aka LaTeX ;-) asks for "Adobe Helvetica", it gets the font metrics from "phv....tfm". Then, in the map files the users decides whether to use the original adobe fonts or the substitues.
Right, and that is why so many docs look bad! Those metrics differ. The same for times: adobe times metrics even differ/change over time (nelson beebe has done some excellent research on this; see pdftex mail archives); this is the main reason why i stick to urw times and palatino etc. Also, they go well with math times (tx) and math palatino (px).
2) TeX macro package (aka ConTeXt ;-) asks for "URW Nimbus Sans" a) on TeXlive (and perhaps any other I don't kown of) it gets the metrics from "uhv....tfm". Then, in the map files the user has no choice; the dvi/pdf driver should take Nimbus Sans.
well, context users should have gs on their system anyway since it's a great tool for previewing (in th eprocess of stylewriting).
b) on teTeX (+...?) with some special mappings it gets the "phv....tfm" metrics. Then see above at 1).
I think it is wrong behaviour to explicitly ask for the substitution and leave the user no choice about which variant (adobe, urw) to use.
hm, but you can of course make a typescript: berry-adobe
concerning the broken german ss: the polish font gurus (you'll meet them at the dante meeting) have made extended versions of those urw fonts, so maybe that will help. [the normal urw also don't have ogoneked glyphs]
Well, concerning the ss: Just install the Adobe Helvetica (free) and that's it (except for patching ConTeXt ;-)
well, as far as i know adobe stopped adding the famou s15 to distributions; also, beware: acrobat will replace helvetica etc by the system specific preference, which of course has different metrics (arial on windows), and again, is one reason why files start looking real ugly. so, i play safe, but as said, if you provide additional typescripts ... Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
Hans Hagen
1) TeX macro package (aka LaTeX ;-) asks for "Adobe Helvetica", it gets the font metrics from "phv....tfm". Then, in the map files the users decides whether to use the original adobe fonts or the substitues.
Right, and that is why so many docs look bad! Those metrics differ.
But they would not look better if you use NimbusSans! (Germandbls)
The same for times: adobe times metrics even differ/change over time (nelson beebe has done some excellent research on this; see pdftex mail archives);
Does anybody have a pointer to this? I haven't found it.
this is the main reason why i stick to urw times and palatino etc. Also, they go well with math times (tx) and math palatino (px).
2) TeX macro package (aka ConTeXt ;-) asks for "URW Nimbus Sans" a) on TeXlive (and perhaps any other I don't kown of) it gets the metrics from "uhv....tfm". Then, in the map files the user has no choice; the dvi/pdf driver should take Nimbus Sans.
well, context users should have gs on their system anyway since it's a great tool for previewing (in th eprocess of stylewriting).
It is not a matter of having gs installed or not. Since TeX is just looking for the tfm files, you need them. But is there any TeX System with the tfm file for the urw variants besides TeXlive? TeTeX doesn't have 'em and teTeX is widely distributed. The pfb files from urw are shipped with TeXlive and TeTeX.
b) on teTeX (+...?) with some special mappings it gets the "phv....tfm" metrics. Then see above at 1).
I think it is wrong behaviour to explicitly ask for the substitution and leave the user no choice about which variant (adobe, urw) to use.
hm, but you can of course make a typescript: berry-adobe
Then the mapping (internally) would be Helvetica -> uhv... -> phv I think that this is a useable workaround.
concerning the broken german ss: the polish font gurus (you'll meet them at the dante meeting) have made extended versions of those urw fonts, so maybe that will help. [the normal urw also don't have ogoneked glyphs]
Well, concerning the ss: Just install the Adobe Helvetica (free) and that's it (except for patching ConTeXt ;-)
well, as far as i know adobe stopped adding the famou s15 to distributions;
Right. There are old acroread versions on the adobe site that still have them.
also, beware: acrobat will replace helvetica etc by the system specific preference, which of course has different metrics (arial on windows), and again, is one reason why files start looking real ugly.
But this might still be better then the Nimbus Sans?
so, i play safe, but as said, if you provide additional typescripts ...
OK. I'll do so. I guess I name it adobekb. Patrick
At 09:54 AM 3/13/2003 +0100, you wrote:
It is not a matter of having gs installed or not. Since TeX is just looking for the tfm files, you need them. But is there any TeX System with the tfm file for the urw variants besides TeXlive? TeTeX doesn't have 'em and teTeX is widely distributed.
so we have to convince thomas/sebastian/fabrice/gerben to add them
The pfb files from urw are shipped with TeXlive and TeTeX.
what is the use of pfb's without the tfm's
hm, but you can of course make a typescript: berry-adobe
Then the mapping (internally) would be
Helvetica -> uhv... -> phv
I think that this is a useable workaround.
or directly Helvetica -> phv by an typescript that overloads
OK. I'll do so. I guess I name it adobekb.
ok ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
On Thursday 13 March 2003 07:37 am, Hans Hagen wrote: (snip) Is it possible to take a deep breath and go back to the starting point, the TeX primitive \font? It allows one to name a specific font as listed in e.g. psfonts.map or some other designated mapping file. Control is absolute. You specify the font and if it is listed and installed you get it, in the size you specify. As a practical matter I seldom need a font in more than two sizes, and if I do then I can just dupe the \font statement, change the name and change the size parameter. Unfortunately Context has a much more elaborate, indirect and confusing (to me at least) mechanism embedded. Now, starting from this \font base, how do we add features without losing simplicity and basic control? Stated another way, how can one create \font statements and alias them into the Context font handling system without too much grief? Fonts are the most troublesome aspect of TeX in all versions, from plain TeX on forward. The mission is not to add complexity, difficulty and confusion but to reduce them. We need a simpler way to install fonts and a simpler and more direct way to call for them. IMHO of course. John Culleton Able Indexers and Typesetters
At 10:07 AM 3/13/2003 -0500, you wrote:
On Thursday 13 March 2003 07:37 am, Hans Hagen wrote:
(snip) Is it possible to take a deep breath and go back to the starting point, the TeX primitive \font? It allows one to name a specific font as listed in e.g. psfonts.map or some other designated mapping file. Control is absolute. You specify the font and if it is listed and installed you get it, in the size you specify. As a practical matter I seldom need a font in more than two sizes, and if I do then I can just dupe the \font statement, change the name and change the size parameter. Unfortunately Context has a much more elaborate, indirect and confusing (to me at least) mechanism embedded.
Now, starting from this \font base, how do we add features without losing simplicity and basic control? Stated another way, how can one create \font statements and alias them into the Context font handling system without too much grief?
\definefont[whatever][somename at somesize] \whatever [or slightly more extensive (see chinese, symbols etc, for adaptive definitions)]
Fonts are the most troublesome aspect of TeX in all versions, from plain TeX on forward. The mission is not to add complexity, difficulty and confusion but to reduce them. We need a simpler way to install fonts and a simpler and more direct way to call for them.
IMHO of course.
If you stick to english, fonts are less a problem since you can stick to tex's default encoding or whatever is at hand; however, it happens that most of us use more extensive char sets, and that each language has its own patterns, encodings, alternative glyphs etc. Also, as soon as math shows up, one needs a consistent sub subsub system, so this adds to the complication. And then, users want to combine fonts from different verdors, so we get typefaces (in context) and relative scaling, and specific interlinespace, and ... and ... Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
Hans Hagen
The pfb files from urw are shipped with TeXlive and TeTeX.
what is the use of pfb's without the tfm's
Used for substituion, I guess. pdftex will include those then. I takes metrics from p* and includes u*.
hm, but you can of course make a typescript: berry-adobe
OK, done. Still in testing state.
I think that this is a useable workaround.
or directly Helvetica -> phv by an typescript that overloads
I am still not sure how to do this. But I had no close look at the type-* files yet. Patrick
At 07:05 PM 3/21/2003 +0100, you wrote:
Used for substituion, I guess. pdftex will include those then. I takes metrics from p* and includes u*.
it may be more complicates, esp if there wre virtual fonts involved, in which case tex uses a file "abc.tfm" and pdftex (dvips) also uses a vf file "def.vf" ; it's for this reason that i let texfont use the same names prefixed with raw, so that at least i *know* what happens without the need to look into the tfm/vf files Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
Right, and that is why so many docs look bad! Those metrics differ. The same for times: adobe times metrics even differ/change over time (nelson beebe has done some excellent research on this; see pdftex mail archives); this is the main reason why i stick to urw times and palatino etc. Also, they go well with math times (tx) and math palatino (px).
Even worse with some Linotype fonts: They even changed the encoding without changing the name on "Linotype Gold 6". Ok, now it's fixed, but only after some firms refused to pay their ten thousand euro licenses for a software that only causes trouble...
well, as far as i know adobe stopped adding the famous 15 to distributions; also, beware: acrobat will replace helvetica etc by the system specific preference, which of course has different metrics (arial on windows), and again, is one reason why files start looking real ugly.
No, not system specific: Acrobat is delivered with Arial, TimesNewRoman etc. even for Macintosh! (since Acrobat 4) Grüßlis vom Hraban! -- www.fiee.net/texnique/
then, how many people do have the adobe palatino's? None that I know of.
You know me. ;-) (Ok, I got them only at work.)
concerning the broken german ss: the polish font gurus (you'll meet them at the dante meeting) have made extended versions of those urw fonts, so maybe that will help. [the normal urw also don't have ogoneked glyphs]
I very hope that they did ask URW before -- AFAIK they aren't public domain or so but only freeware. And it would be a pity if they wouldn't allowed to spread their work.
Well, concerning the ss: Just install the Adobe Helvetica (free) and that's it (except for patching ConTeXt ;-)
Helvetica belongs to the standard PS fonts as Palatino does, but none of them is free! At Adobe the standard fonts are a bit less costly than other, but nevertheless to pay. Ok, there are several possibilities to get at least the standard 13 from an older Acrobat or so... Grüßlis vom Hraban! -- www.fiee.net/texnique/
Henning Hraban Ramm
Well, concerning the ss: Just install the Adobe Helvetica (free) and that's it (except for patching ConTeXt ;-)
Helvetica belongs to the standard PS fonts as Palatino does, but none of them is free! At Adobe the standard fonts are a bit less costly than other, but nevertheless to pay.
Ok, there are several possibilities to get at least the standard 13 from an older Acrobat or so...
that is what I meant. And I was talking only about Helvetica. Greetings, Patrick
At 02:04 PM 3/12/2003 +0100, you wrote:
It is clearer: the first bit gives the encoding and the latter bit is the name of the file containign the glyphs (uplr8a.pfb). OTOH since LaTeX already creates a lot of font-mess, I do agree that there is no need to add more to the trouble already there. I would like to see a few sym-links (does Windows have something like that?) to add a few names to the tree to make sure everything works as planned.
the tricky part is in slanted, extended and caps'd fonts, where there is no distinction between instances in psfnss, which is why context has more verbose names; also, most of the fonts we use here (in projects) are not free, not in the texmf tree, and i have no time (or spirit) to sort out how they should be reduced to 2+2+2+2 char names; so, this iw why the berry typescripts permit you to use the rare texmf-tree names, while additional fonts can follow the more verbose scheme (unless of course one sorts out the funny short name and names the fonts manually). Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
Bruce D'Arcus said this at Tue, 11 Mar 2003 09:34:08 -0500:
On Tuesday, March 11, 2003, at 03:00 AM, Hans Hagen wrote:
Also, IIRC, shouldn't the grey border surround the entire page, and extend to the edge? I am getting a thinner border in the shape of an "L," with white space at the page edge.
works ok here, puzzled
Bruce, did you try opening the file in Acrobat? It's based on a very nice 2-page spread layout, and the page structure is immediately apparent once you see it that way.
On this, the only thing I changed was to use a different font, since palatino doesn't seem to work from ConTeXt in my new installation.
One word: texfont. It took me a while to figure out how to actually use it on my MacOSX (TeXLive) install, but it works very nicely, once you figure out a couple stumbling blocks. I actually wrote a My Way tutorial on it, but it ended up being a bit too cranky. Hans took it more as a bug report, and said he'd work on some of the issues I brought up. So I'm not sure whether I should release it as-is, or if I should wait for texfont to change.
I know this was discussed previously, but don't remember the bottomline point. Shouldn't these fonts that are included with teTeX and TeXLive just work in ConTeXt, without needing any intervention by the user? If yes, whose responsibility is this? Am using Gerben Wierda's OS X installer, but have a feeling this isn't his problem. Or maybe it is?
basically what I did was: set teTeX = /usr/local/teTeX # my tcsh setting of the root tex install cd $teTeX # wherever you have your root tetex directory sudo chgrp -R admin texmf-local # make your texlocal directory sudo chmod -R g+w texmf-local # group-writeable to facilititate changes cd texmf/fonts # copy the fonts into the local font directory for munging the names cp -R afm tfm type1 vf ../../texmf-local/fonts/ cd ../../texmf-local/fonts/afm mv bit bitstrea # correct a TeXLive 7 naming bug gunzip -r * # I think these are shipped as gzipped files sudo texhash cd # or to a safe home directory where temp files can be created # next command is all one line: texfont $teTeX/texmf/context/data/type-tmf.dat --en=texnansi --fontroot=$teTeX/texmf-local --install --makepath it'll make a bunch of font charts in the form of .tex files. To run these (and use the palatino fonts in s-mag) you ought to have \autoloadmapfiletrue in your cont-sys.tex file. I *think* that'll get you started. Good luck... adam -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay atl@comp.lancs.ac.uk Computing Dept, Lancaster University +44(0)1524/594.537 Lancaster, LA1 4YR, UK Fax:+44(0)1524/593.608 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
At 03:02 PM 3/11/2003 +0000, you wrote:
So I'm not sure whether I should release it as-is, or if I should wait for texfont to change.
just release it and update it when i did the patch (which actually reminds me that i need to patch; sorry, too busy catching up with stabelizing some nasty features) Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
"Bruce D'Arcus"
Hans, are you saying anyone using this to produce a document ought to keep the title specified in the style (which here seems to be {Zero Issue}? In any case, this is confusing (at least to me)...
The user variant has the title "My Way". No number.
Also, IIRC, shouldn't the grey border surround the entire page, and extend to the edge? I am getting a thinner border in the shape of an "L," with white space at the page edge.
with the following document I get a simple magazine text: ================================================== \setupencoding[default=8r] \usetypescript[tetex][\defaultencoding] \usemodule[mag-01] \setvariables [magazine] [title={Nonsense in Typography}, author=A.~U.~Thor, ] \startbuffer[abstract] \input knuth \stopbuffer \starttext \setups [titlepage] \setups [title] \section{Preface} \input knuth \section{Useless} \input tufte \stoptext ================================================== -- Mehr Buchstaben - mehr Spass
At 05:25 PM 3/10/2003 +0100, you wrote:
Hello list,
I wish to bring the discussion again on displayed material. Display material is material that conceptually belongs to a paragraphs but typographically breaks it. After the display, the paragraph can continue or not. In ConTeXt, there are many things which should be considered displayed material: formulas, enumerations and other itemgroups, quotations, etc. Every start/stop pair that begins a new paragraph should actually be a displayed area. In ConTeXt, one can achieve such result by using [intentnext=yes] or [indentnext=no] on a case-by-case basis, depending on whether the start/stop pair is supposed to start a new paragraph or not. Of course, this "manual" way to do the thing goes against the general principle that the computer is supposed to do as much of the job as possible, by itself. I therefore wish to urge Hans to implement a new indentnext option, "auto", which should give a behaviour similar to the one shown on this example:
well it's on my todo list to provide this option, but first i need to finish a couple of grid things; actually live would be much easier if there wer \bpar \epar commands -) Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
At 05:25 PM 3/10/2003 +0100, you wrote:
to do as much of the job as possible, by itself. I therefore wish to urge Hans to implement a new indentnext option, "auto", which should give a behaviour similar to the one shown on this example:
btw, here are shorter defs: \def\startdisplay {\relax\ifvmode\else\endgraf\noindent\fi\ignorespaces} \def\stopdisplay {\par\doifnextcharelse\par\donothing\noindent} watch the \relax (prevents lookahead) and \doifnextcharelse anyway, isn't a \stopdisplay followed by an empty line still supposed to be a display?, so the full model is: \startparagraph text or not \startdisplay \stopdisplay text or not \stopparagraph the startparagraph and stopparagraph can be kind of automatic, but that's just an added bonus for those who want to use empty lines as signals (something which is not common, for instance in xml where proper tagging takes place). Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
Tuesday, March 11, 2003 Hans Hagen wrote: HH> btw, here are shorter defs: HH> \def\startdisplay HH> {\relax\ifvmode\else\endgraf\noindent\fi\ignorespaces} HH> \def\stopdisplay HH> {\par\doifnextcharelse\par\donothing\noindent} HH> watch the \relax (prevents lookahead) and \doifnextcharelse Good to know, thanks. BTW, have you had a look at the patches I submitted to the list around 10pm yesterday? What do you think of them? HH> anyway, HH> isn't a \stopdisplay followed by an empty line still supposed to be a HH> display? Yes it is, and it conceptually belongs to the previous paragraph, but the following text is not part of the same paragraph and should therefore start with indentation. HH> , so the full model is: HH> \startparagraph HH> text or not HH> \startdisplay HH> \stopdisplay HH> text or not HH> \stopparagraph HH> the startparagraph and stopparagraph can be kind of automatic, but that's HH> just an added bonus for those who want to use empty lines as signals HH> (something which is not common, for instance in xml where proper tagging HH> takes place). Anything that gives a "paragraph end" should work. This is why in the patches I submitted I made a small change: it suffices to give a \noindent, regardless of what comes after, so that: (1) if paragraph doesn't end (by any mean: no \par, no empty line, no </para>), the next text will typographically belong to the same paragraph (i.e. will not be indented) (2) if paragraph ends (by any mean: \par, empty line, </para>), the next text will be indented, since the paragraph end will "absorb" the \noindent. -- Giuseppe "Oblomov" Bilotta
At 11:08 AM 3/11/2003 +0100, you wrote:
Tuesday, March 11, 2003 Hans Hagen wrote: HH> btw, here are shorter defs:
HH> \def\startdisplay HH> {\relax\ifvmode\else\endgraf\noindent\fi\ignorespaces}
HH> \def\stopdisplay HH> {\par\doifnextcharelse\par\donothing\noindent}
HH> watch the \relax (prevents lookahead) and \doifnextcharelse
Good to know, thanks. BTW, have you had a look at the patches I submitted to the list around 10pm yesterday? What do you think of them?
What patch? Yesterday around 10 i was deparately trying to figure out why our (linux) mail server was infected by a spammer (some kind of sendmail bug combined with pop3 things) and in the process (took me the whole morning) probably lost some mails. Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
Tuesday, March 11, 2003 Hans Hagen wrote: HH> What patch? Yesterday around 10 i was deparately trying to figure out why HH> our (linux) mail server was infected by a spammer (some kind of sendmail HH> bug combined with pop3 things) and in the process (took me the whole HH> morning) probably lost some mails. Ok, here it is: """ Anyway, I built a "quick and dirty" patch which seems to work for most environments which, I think, require it: itemgroups, definitions, formulas, verbatim. You can put it in your cont-loc between \unprotect ... \protect pairs: === BEGIN PATCH === \startvariables all auto: auto \stopvariables \def\@@stopdefinitie#1% {\par \dostopattributes \endgroup \getvalue{\??dd#1\c!na}% \egroup % temporary hack \doifvalue{\??dd#1\c!springvolgendein}\v!nee\noindentation \doifvalue{\??dd#1\c!springvolgendein}\v!auto\noindent} \def\stopitemgroup {\iftextitems \removeunwantedspaces\space\ignorespaces \else \par \fi \ifnum\itemcolumndepth=\zerocount \dolistreference \fi % beware ! \iffirstlist \else \endgroup \fi % toegevoegd, eerste \som opent groep \ifnum\itemcolumndepth=\itemlevel\relax \stopkolommen \doglobal\newcounter\itemcolumndepth \getitemparameter\itemlevel\c!na \else \ifnum\itemlevel=\plusone \doitembreak\allowbreak % toegevoegd \getitemparameter1\c!na \doif\@@oospringvolgendein\v!nee\noindentation \doif\@@oospringvolgendein\v!auto\noindent \fi \fi \endgroup \doglobal\decrement(\itemlevel,\itemincrement)% \egroup} \def\dostopformula {\doplaceformulanumber \getvalue{\e!stop\getvalue{\??fm\currentformula\c!variant}\e!formule}% \resetlastlinewidth \nonoindentation \doifvalue{\??fm\currentformula\c!springvolgendein}\v!nee\noindentation \doifvalue{\??fm\currentformula\c!springvolgendein}\v!auto\noindent \egroup} \def\dostoptyping#1% {\stopverbatimcolor \stopopelkaar % includes \egroup \getvalue{\??tp#1\c!na}% \doifvalue{\??tp#1\c!springvolgendein}\v!nee\noindentation \doifvalue{\??tp#1\c!springvolgendein}\v!auto\noindent} === END PATCH === Remember to issue the following instructions: \setupformulas[indentnext=auto] \setupitemgroups[indentnext=auto] to make it work. No need to regenerate the formats (you may need to refresh the filename database if you didn't have a cont-loc.tex before that). Hans, can we hope for this to go into the core for the next beta? Note: while I think it should be done for quotations as well, this seems to be a feature "in development" so I won't touch it for now. -- Giuseppe "Oblomov" Bilotta
At 12:47 PM 3/11/2003 +0100, you wrote:
Anyway, I built a "quick and dirty" patch which seems to work for most environments which, I think, require it: itemgroups, definitions, formulas, verbatim. You can put it in your cont-loc between \unprotect ... \protect pairs:
This is dangerous! better put it into cont-min.tex and load that one in yoru cont-sys.tex file \readfile{yourfile}\donothing\donothing or so. Cont-loc.tex is a personal extensions (there i put patches that i test for some time before they make it into the kernel; i also have a cont-exp for experiment, like dirty speedups); since these file are not distributed, there is a danger in them being on someones system and being loaded. Also, something: \overloaded \def \somehack ... may warn you for such dangers. Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
Tuesday, March 11, 2003 Hans Hagen wrote: HH> At 12:47 PM 3/11/2003 +0100, you wrote:
Anyway, I built a "quick and dirty" patch which seems to work for most environments which, I think, require it: itemgroups, definitions, formulas, verbatim. You can put it in your cont-loc between \unprotect ... \protect pairs:
HH> This is dangerous! better put it into cont-min.tex and load that one in HH> yoru cont-sys.tex file HH> \readfile{yourfile}\donothing\donothing HH> or so. Cont-loc.tex is a personal extensions (there i put patches that i HH> test for some time before they make it into the kernel; i also have a HH> cont-exp for experiment, like dirty speedups); since these file are not HH> distributed, there is a danger in them being on someones system and being HH> loaded. I thought that cont-new was for the temporary patches and cont-loc for the local extensions? Since cont-loc is not distributed with the normal ConTeXt distribution, it makes sense to put it there, doesn't it? HH> Also, something: HH> \overloaded \def \somehack ... HH> may warn you for such dangers. That's good to know. HH> \def\synchronizeindentation HH> {% HH> \doifvalue{\??dd#1\c!springvolgendein}\v!nee\noindentation HH> \doifvalue{\??dd#1\c!springvolgendein}\v!auto\noindent} HH> }% HH> HH> saves keying and also provides a hook Right :) I expect to see it in the core for the next release! ;) -- Giuseppe "Oblomov" Bilotta
At 06:04 PM 3/11/2003 +0100, you wrote:
HH> \def\synchronizeindentation HH> {% HH> \doifvalue{\??dd#1\c!springvolgendein}\v!nee\noindentation HH> \doifvalue{\??dd#1\c!springvolgendein}\v!auto\noindent} HH> }% HH> HH> saves keying and also provides a hook
Right :) I expect to see it in the core for the next release! ;)
Ha, i found out that i already had a \checknextindentation in my cont-loc (for different purposes -) anyhow, i'll provide you the hook Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
Wednesday, March 12, 2003 Hans Hagen wrote:
Right :) I expect to see it in the core for the next release! ;)
HH> Ha, i found out that i already had a HH> \checknextindentation in my cont-loc HH> (for different purposes -) HH> anyhow, i'll provide you the hook Even better, put the indentnext=auto code in the core :) -- Giuseppe "Oblomov" Bilotta
At 10:36 AM 3/13/2003 +0100, you wrote:
Wednesday, March 12, 2003 Hans Hagen wrote:
Right :) I expect to see it in the core for the next release! ;)
HH> Ha, i found out that i already had a HH> \checknextindentation in my cont-loc HH> (for different purposes -)
HH> anyhow, i'll provide you the hook
Even better, put the indentnext=auto code in the core :)
don't hurry too much, if you define yourself a \autoindentation macro you'll have indentnext=auto Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
At 12:47 PM 3/11/2003 +0100, you wrote: \def\synchronizeindentation {%
\doifvalue{\??dd#1\c!springvolgendein}\v!nee\noindentation \doifvalue{\??dd#1\c!springvolgendein}\v!auto\noindent} }%
saves keying and also provides a hook Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
At 12:47 PM 3/11/2003 +0100, you wrote:
=== BEGIN PATCH === \startvariables all auto: auto \stopvariables
ok, added, does not hurt to have that key (althougj in this case 'display' i smore adequate
\def\@@stopdefinitie#1% \def\stopitemgroup \def\dostopformula \def\dostoptyping#1%
simple test replaced by \(do)checknextindentation CORE-ITM.TEX: CORE-MAT.TEX: CORE-MIS.TEX: CORE-SEC.TEX: CORE-SPA.TEX: CORE-VER.TEX: PAGE-ONE.TEX: PAGE-SET.TEX:
before that). Hans, can we hope for this to go into the core for the next beta?
i'll upload a beta for you to test
Note: while I think it should be done for quotations as well, this seems to be a feature "in development" so I won't touch it for now.
added anyway also, auto invokes \autoindentation, so for the moment you have to hook you rown code in there (\relax by default) [later i will look into a proper display something; needs to work ok with the nex par hooks in cont-new] happy indenting Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
Wednesday, March 12, 2003 Hans Hagen wrote: HH> At 12:47 PM 3/11/2003 +0100, you wrote:
=== BEGIN PATCH === \startvariables all auto: auto \stopvariables
HH> ok, added, does not hurt to have that key (althougj in this case 'display' HH> i smore adequate I don't think so. The material is displayed anyway. The key value should simply make a different from yes/no (i.e. "decide automatically"), it doesn't change the "logical" nature of the block ... but anyway :) HH> i'll upload a beta for you to test Thanks :) -- Giuseppe "Oblomov" Bilotta
participants (9)
-
Adam Lindsay -
Bruce D'Arcus -
Giuseppe Bilotta -
Hans Hagen -
Henning Hraban Ramm -
Jens-Uwe Morawski -
John Culleton -
Maarten Sneep -
Patrick Gundlach