Suggestion

Suggestion

[David Arnold]

Could this list somehow send out information that messages being received
are from the Context list. For example, messages I receive from the Miktex
list always have subject lines that look like this:

[Miktex]: Additional texmf tree

This would be helpful in recognizing what is coming from Context.

Just a suggestion.

Re: Suggestion

[Hans Hagen]

David Arnold wrote:

> This would be helpful in recognizing what is coming from Context.
> 
> Just a suggestion.

I forwarded it to the supreme listcommander of the ntg. 

Hans

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.nl
-----------------------------------------------------------------

Re: Suggestion

[Arthur Reutenauer]

> The key reason for this is, more people are familiar with regexp. so
> if you can build a 100% compatible regexp module on top of lpeg in
> ConTeXt, it will be ok, or even better...

  There *is* a regexp module on top of LPeg.  It's written by Roberto
Ierusalimschy, the Lua and LPeg author.  Just use it if you want.

	http://www.inf.puc-rio.br/~roberto/lpeg/re.html

		Arthur
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Suggestion

[luigi scarso]

[-- Attachment #1.1: Type: text/plain, Size: 2167 bytes --]

On Fri, Jun 19, 2009 at 9:06 AM, Yue Wang <yuleopen@gmail.com> wrote:

> On Fri, Jun 19, 2009 at 2:29 PM, luigi scarso<luigi.scarso@gmail.com>
> wrote:
> >>
> >> Anyway, I highly respect the ConTeXt and LuaTeX's work.
> >> But if Taco and Hans can :
> >>
> >> - use a proper regexp library (like lrexlib?), not the silly lpeg
> >
> > PEG are not silly at all. PEG *include* regex, but not viceversa,
> > and it seems to have the same power of  CFG, so you can build a parser
> for
> > pratically anything
> > (and you can not do this with regex) .
> > Perhaps the reverse sentence has more sense: drop the "silly" (?) regex,
> use
> > the new peg.
> > For what I know the reverse side of lpeg is that a file must be loaded in
> > memory completly.
>
> Well, I don't like to know what kind of thing is superior ... micro
> kernel is superior than monolithic kernel, but...
>
Wrong paragon .
>From *mathematical*  point  of  view, the set of all regular languages
are a subset of PEG languages .
PEG are more powerful than  regex --it's not an opinion, it's a fact.


> The key reason for this is, more people are familiar with regexp. so
> if you can build a 100% compatible regexp module on top of lpeg in
> ConTeXt, it will be ok, or even better...
>
We already have lua for simple string manipulation, and lpeg for other
stuffs .
Again we don't need regex .


> >
> >> - full support of xslt:)
> >
> > why not xquery too? Are mkiv  supposed to be a full  xml processor ?
>
>
> No. I mean the user can have an option to convert an xml (that is, a
> context document) using (maybe external) xslt tool.
> This won't be too difficult to implement ...
>
hmm, external tools call for platform /SO issue ...
Personally xsltproc in linux it's OK -- I don't need
an integration ,
I prefear separations of concerns.



>
> > A bit of xslt can be done with lpeg (and not regex),
>
> a bit == far from all
>
It's enough for simple xml processing .
If you need more, are you sure that you are using  the right tool ?



>
> >> Things might be a lot better...
> >
> > and worse too .
> > Things are now a lot better than before ,IMMO .
> >
>
> it should be.
>

It is .
-- 
luigi

[-- Attachment #1.2: Type: text/html, Size: 3597 bytes --]

[-- Attachment #2: Type: text/plain, Size: 487 bytes --]

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Suggestion

[Yue Wang]

On Fri, Jun 19, 2009 at 2:29 PM, luigi scarso<luigi.scarso@gmail.com> wrote:
>>
>> Anyway, I highly respect the ConTeXt and LuaTeX's work.
>> But if Taco and Hans can :
>>
>> - use a proper regexp library (like lrexlib?), not the silly lpeg
>
> PEG are not silly at all. PEG *include* regex, but not viceversa,
> and it seems to have the same power of  CFG, so you can build a parser for
> pratically anything
> (and you can not do this with regex) .
> Perhaps the reverse sentence has more sense: drop the "silly" (?) regex, use
> the new peg.
> For what I know the reverse side of lpeg is that a file must be loaded in
> memory completly.

Well, I don't like to know what kind of thing is superior ... micro
kernel is superior than monolithic kernel, but...

The key reason for this is, more people are familiar with regexp. so
if you can build a 100% compatible regexp module on top of lpeg in
ConTeXt, it will be ok, or even better...

>
>> - more powerful multi columns (maybe not through gird typesetting?)
>
> Maybe columnset can do  more, or we need more examples from hans .
>

yes. but columnset requires more strict rules (e.g., grid stuffs)
why not build a version of columnset on top of normal TeX page building?
(grid can be a option, should not be a requirement)

>
>> - full support of xslt:)
>
> why not xquery too? Are mkiv  supposed to be a full  xml processor ?


No. I mean the user can have an option to convert an xml (that is, a
context document) using (maybe external) xslt tool.
This won't be too difficult to implement ...

> A bit of xslt can be done with lpeg (and not regex),

a bit == far from all

> but usually  it's better to prepare a xml to typeset before processing with
> mkiv
> ("use the right tool for the right task").
>
>>
>> Things might be a lot better...
>
> and worse too .
> Things are now a lot better than before ,IMMO .
>

it should be.

>
> --
> luigi
>
>
> ___________________________________________________________________________________
> If your question is of interest to others as well, please add an entry to
> the Wiki!
>
> maillist : ntg-context@ntg.nl /
> http://www.ntg.nl/mailman/listinfo/ntg-context
> webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
> archive  : https://foundry.supelec.fr/projects/contextrev/
> wiki     : http://contextgarden.net
> ___________________________________________________________________________________
>
>
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Suggestion

[luigi scarso]

[-- Attachment #1.1: Type: text/plain, Size: 1071 bytes --]

>
>
> Anyway, I highly respect the ConTeXt and LuaTeX's work.
> But if Taco and Hans can :
>
> - use a proper regexp library (like lrexlib?), not the silly lpeg

PEG are not silly at all. PEG *include* regex, but not viceversa,
and it seems to have the same power of  CFG, so you can build a parser for
pratically anything
(and you can not do this with regex) .
Perhaps the reverse sentence has more sense: drop the "silly" (?) regex, use
the new peg.
For what I know the reverse side of lpeg is that a file must be loaded in
memory completly.

- more powerful multi columns (maybe not through gird typesetting?)
>
Maybe columnset can do  more, or we need more examples from hans .


- full support of xslt:)
>
why not xquery too? Are mkiv  supposed to be a full  xml processor ?
A bit of xslt can be done with lpeg (and not regex),
but usually  it's better to prepare a xml to typeset before processing with
mkiv
("use the right tool for the right task").


> Things might be a lot better...
>
and worse too .
Things are now a lot better than before ,IMMO .


-- 
luigi

[-- Attachment #1.2: Type: text/html, Size: 1887 bytes --]

[-- Attachment #2: Type: text/plain, Size: 487 bytes --]

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Suggestion

[Yue Wang]

On Mon, Jun 15, 2009 at 7:55 PM, Arun Dev<arundvrjn@gmail.com> wrote:
>
> Hi,
>
>         You can increase the popularity of ConTeXt by eliminating the need
> to install Perl and Ruby.
>

MKIV does not dependent on Perl and Ruby.
I think Hans has plan to convert the MKII scripts to Lua language.


Anyway, I highly respect the ConTeXt and LuaTeX's work.
But if Taco and Hans can :

- use a proper regexp library (like lrexlib?), not the silly lpeg
- make font loading faster (by massive fontforge change or replace it
with ft2+libotf. we need more efficient solution esp for big fonts)
- support TeX line-break-like page break
- support arbitrary text-flow maybe via mplib (example: The ultimate
(?) float problem + How could a typesetting system be today? on
mailing list )
- make processing conditional-aware (see "two newbie questions about
conditional processing" on the mailing list)
- fix the bug of focus=standard
- more powerful multi columns (maybe not through gird typesetting?)
- full support of xslt:)

Things might be a lot better...


> ___________________________________________________________________________________
> If your question is of interest to others as well, please add an entry to
> the Wiki!
>
> maillist : ntg-context@ntg.nl /
> http://www.ntg.nl/mailman/listinfo/ntg-context
> webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
> archive  : https://foundry.supelec.fr/projects/contextrev/
> wiki     : http://contextgarden.net
> ___________________________________________________________________________________
>
>
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Suggestion

[Taco Hoekwater]

R. Bastian wrote:
> 
> - Perl, Ruby, Python and others are installed per default on most working computers,
> - TeX alone has not enough power.

luatex does have that power.

> What is needed is documentation : I dont know the meaning of [...1...][...2 ...]

This is actually explained in chapter one of the manual:

  http://www.pragma-ade.com/general/manuals/cont-eni.pdf

Best wishes,
Taco
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: Suggestion

[R. Bastian]

On Mon, 15 Jun 2009 17:25:32 +0530
Arun Dev <arundvrjn@gmail.com> scribit:

> Hi,
> 
>         You can increase the popularity of ConTeXt by eliminating the need
> to install Perl and Ruby.

I dont think so. 

- Perl, Ruby, Python and others are installed per default on most working computers,
- TeX alone has not enough power.

What is needed is documentation : I dont know the meaning of [...1...][...2 ...]


René B.
-- 

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Suggestion

[Arun Dev]

[-- Attachment #1.1: Type: text/plain, Size: 106 bytes --]

Hi,

        You can increase the popularity of ConTeXt by eliminating the need
to install Perl and Ruby.

[-- Attachment #1.2: Type: text/html, Size: 128 bytes --]

[-- Attachment #2: Type: text/plain, Size: 487 bytes --]

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: suggestion

[Daniel Pittman]

On Mon, 28 Jan 2002, Patrick Gundlach wrote:

[...]

> More important is to "rate" the questions:
> 
> 1) is it a question to wich the answer can be found in the 
> manual? Then there is already a documentation for it and we do 
> not need to answer it again.

Heh. My question, about why my table content didn't lay out correctly,
was documented in the manual. Sure, it was my stupidity, but I managed
to miss the vital detail when reading.

The FAQ is an /alternate/ indexing system, as much as anything, for this
sort of question. :)

        Daniel

-- 
As an adolescent I aspired to lasting fame, I craved factual certainty, and I
thirsted for a meaningful vision of human life -- so I became a scientist.
This is like becoming an archbishop so you can meet girls.
        -- Matt Cartmill

Re: suggestion

[Hans Hagen]

At 02:02 PM 1/28/2002 +0100, Eckhart Guthöhrlein wrote:

>>6) request for improvements. They are probably documented in Hans' privat 
>>todo list... I there a need to collect them? I think yes.
>
>
>We would have to decide what wishes should be put on the todo list. I 
>think not everything a single person might want to have can actually be 
>included, that's why a todo list with priorities would be useful. One of 
>the key factors for determining this priority are certainly Hans' own 
>needs and projects, so the best place for the list is in his hands - where 
>it is.

currently when someone expresses a wish, i kind of decide on the fly to add 
it or not; some extensions are just adding a couple of lines, but more 
complex wishes, which demand an overhaul (or depend on other work in 
progress) go onto the todo list;

i indeed do have a todo list somewhere (stacks of notes) so you may expect 
extensions for the next couple of years.

fortunately we have a couple of demanding projects which result in new 
mechanisms; unfortunately the docu lags behind then

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
-------------------------------------------------------------------------
                                   fall-back web server: 
www.pragma-pod.nl
-------------------------------------------------------------------------

Re: suggestion

[Eckhart Guthöhrlein]

Sorry, accidentally pressed the send button ;-) Completed version follows.

Patrick Gundlach wrote:

> We have to analyse the questions asked on the list. In my 
> opinion it does not make sens just to copy the question and the 
> correct answer and make a digest. This would not do any good, 
> because we then just have a mere copy of the mailinglist 
> (stripped down to the essentials, indeed)
> 
> More important is to "rate" the questions:

I agree with you. As Hans suggested, everybody could compile a QA for 
his particular case. But for a sensible faq - if we want it - one person 
will probably have to edit and sort them.

> 1) is it a question to wich the answer can be found in the 
> manual? Then there is already a documentation for it and we do 
> not need to answer it again.

Optimistic.

> 2) is it a question that has not yet been documented? Say for 
> example "how can I draw a line below the headline?". (I actually 
> do not know if this is in the manual). In this case, we (Hans :->
> ) should see this as an opportunity to add a few lines to the 
> manual, so the next time this questions will not be asked again.

I don't know if Hans has enough time to update the documentation 
continually... Perhaps an entry in our list, which can be removed by the 
maintainer if updated documentation becomes available.

> 3) a questions that is related to the installation. For example 
> the texhash or mktexlsr thing. Or the cont-sys.ori/cont-sys.tex 
> stuff. I think these are worth being documented in some extra 
> document.

Shouldn't this go into the existing installation instructions? (Or to 
the faq, in the meantime...)

> 4) bug reports. We do not need to collect them, since one hour 
> later 96% of them are already fixed. Just search the archive if 
> you have some trouble.

One of the greatest things about context, isn't it?

> 5) Questions regarding fonts/encodings. Yuck. I have no clue what to do 
> with them. There is really something that has to be done. I know 
> that there is are docs. But there are a many questions on the 
> list concerning this subject.

Can't say too much about this. But probably mfonts.pdf is not very 
explicit / understandable / complete if there remain so many questions?

> 6) request for improvements. They are probably documented in 
> Hans' privat todo list... I there a need to collect them? I 
> think yes.

We would have to decide what wishes should be put on the todo list. I 
think not everything a single person might want to have can actually be 
included, that's why a todo list with priorities would be useful. One of 
the key factors for determining this priority are certainly Hans' own 
needs and projects, so the best place for the list is in his hands - 
where it is.

> 7) Questions like "How can this feature xyz (just think of gb's 
> indefinate long page that got cut off after each chapter) be 
> achieved? These questions are often very esoteric. But imho they 
> are worth being collected.

That is at least some kind of a faq, isn't it?

> So what is my conclusion? Ignore some questions, improve the 
> documentation where necessary, collect some stuff for an extra 
> doc. We do not need an faq.

Ok, let's call it 'Miscellaneous Madness' instead of faq, in honour of 
its esoteric parts.

Eckhart

Re: suggestion

[Eckhart Guthöhrlein]

Patrick Gundlach wrote:

> We have to analyse the questions asked on the list. In my 
> opinion it does not make sens just to copy the question and the 
> correct answer and make a digest. This would not do any good, 
> because we then just have a mere copy of the mailinglist 
> (stripped down to the essentials, indeed)

 >

> More important is to "rate" the questions:
> 

I agree with you. As Hans suggested, everybody could compile a QA for his particular case. But for a sensible faq - if we want it - one person will probably have to edit and sort them.

> 1) is it a question to wich the answer can be found in the 
> manual? Then there is already a documentation for it and we do 
> not need to answer it again.

Optimistic.

> 
> 2) is it a question that has not yet been documented? Say for 
> example "how can I draw a line below the headline?". (I actually 
> do not know if this is in the manual). In this case, we (Hans :->
> ) should see this as an opportunity to add a few lines to the 
> manual, so the next time this questions will not be asked again.
> 
> 3) a questions that is related to the installation. For example 
> the texhash or mktexlsr thing. Or the cont-sys.ori/cont-sys.tex 
> stuff. I think these are worth being documented in some extra 
> document.
> 
> 4) bug reports. We do not need to collect them, since one hour 
> later 96% of them are already fixed. Just search the archive if 
> you have some trouble.
> 
> 5) Questions regarding fonts/encodings. Yuck. I have no clue what to do 
> with them. There is really something that has to be done. I know 
> that there is are docs. But there are a many questions on the 
> list concerning this subject.
> 
> 6) request for improvements. They are probably documented in 
> Hans' privat todo list... I there a need to collect them? I 
> think yes.
> 
> 7) Questions like "How can this feature xyz (just think of gb's 
> indefinate long page that got cut off after each chapter) be 
> achieved? These questions are often very esoteric. But imho they 
> are worth being collected.
> 
> So what is my conclusion? Ignore some questions, improve the 
> documentation where necessary, collect some stuff for an extra 
> doc. We do not need an faq.
> 
> 
> 
> 
> 
> Viele Grüße,
> 
>   Patrick Gundlach
> 
> 
> 
> 

Re: suggestion

[Taco Hoekwater]

On Mon, 28 Jan 2002 11:59:27 +0100
"Patrick Gundlach" <gundlach@irb.cs.uni-dortmund.de> wrote:

> 4) bug reports. We do not need to collect them, since one hour 
> later 96% of them are already fixed. Just search the archive if 
> you have some trouble.

These DO need to be documented. Otherwise, we spend a lot of
time answering questions to people that run into bugs in the
outdated version of context they are using. 

-- 
groeten,

Taco

Re: suggestion

[Hans Hagen]

Hi,

2) is it a question that has not yet been documented? Say for
>example "how can I draw a line below the headline?". (I actually
>do not know if this is in the manual). In this case, we (Hans :->
>) should see this as an opportunity to add a few lines to the
>manual, so the next time this questions will not be asked again.

let's make sure of that; i uploaded a beta version that permits usage of 
before/after, although with some limitations; i hope that this change 
(extension) does not break existing code

%D Although it is far better to use backgrounds for this
%D purpose, one can add a rule in the following way. This
%D method makes the rules disappear in case of an empty text
%D line. Consider this a feature.
%D
%D \starttypen
%D \setupheadertexts[left][right]
%D
%D \setupheader[text][after=\hrule,style=bold]
%D
%D \starttext
%D   \input tufte \page
%D   \setupheader[state=empty]
%D   \input tufte \page
%D \stoptext
%D \stoptypen

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
-------------------------------------------------------------------------
                                   fall-back web server: 
www.pragma-pod.nl
-------------------------------------------------------------------------

Re: suggestion

[Hans Hagen]

At 11:59 AM 1/28/2002 +0100, Patrick Gundlach wrote:

>More important is to "rate" the questions:
>
>1) is it a question to wich the answer can be found in the
>manual? Then there is already a documentation for it and we do
>not need to answer it again.
>
>2) is it a question that has not yet been documented? Say for
>example "how can I draw a line below the headline?". (I actually
>do not know if this is in the manual). In this case, we (Hans :->
>) should see this as an opportunity to add a few lines to the
>manual, so the next time this questions will not be asked again.
>
>3) a questions that is related to the installation. For example
>the texhash or mktexlsr thing. Or the cont-sys.ori/cont-sys.tex
>stuff. I think these are worth being documented in some extra
>document.

or some flow chart or if-then thing; people tend to oversee such things 
when reading a manual

>4) bug reports. We do not need to collect them, since one hour
>later 96% of them are already fixed. Just search the archive if
>you have some trouble.

-)

>5) Questions regarding fonts/encodings. Yuck. I have no clue what to do
>with them. There is really something that has to be done. I know
>that there is are docs. But there are a many questions on the
>list concerning this subject.

this is also related to "if it can be done then people will use it" or if 
you see otehr users use it ... ; this is therefore also a combined user 
effort: providing examples

>6) request for improvements. They are probably documented in
>Hans' privat todo list... I there a need to collect them? I
>think yes.

right, i wonder if we can use bugzilla for this (tobias is looking into 
that for (real big) bugs)

>7) Questions like "How can this feature xyz (just think of gb's
>indefinate long page that got cut off after each chapter) be
>achieved? These questions are often very esoteric. But imho they
>are worth being collected.

right, which makes me wonder why gb is so silent, he must have run out of 
feature requests

>So what is my conclusion? Ignore some questions, improve the
>documentation where necessary, collect some stuff for an extra
>doc. We do not need an faq.

not a faq in the traditional sense; we may need a way to organize examples 
made by users (based on q/a's)

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
-------------------------------------------------------------------------
                                   fall-back web server: 
www.pragma-pod.nl
-------------------------------------------------------------------------

suggestion

[Patrick Gundlach]

Hi,

concerning the suggestion Hans has made, I'd like to add some 
comments:

We have to analyse the questions asked on the list. In my 
opinion it does not make sens just to copy the question and the 
correct answer and make a digest. This would not do any good, 
because we then just have a mere copy of the mailinglist 
(stripped down to the essentials, indeed)

More important is to "rate" the questions:

1) is it a question to wich the answer can be found in the 
manual? Then there is already a documentation for it and we do 
not need to answer it again.

2) is it a question that has not yet been documented? Say for 
example "how can I draw a line below the headline?". (I actually 
do not know if this is in the manual). In this case, we (Hans :->
) should see this as an opportunity to add a few lines to the 
manual, so the next time this questions will not be asked again.

3) a questions that is related to the installation. For example 
the texhash or mktexlsr thing. Or the cont-sys.ori/cont-sys.tex 
stuff. I think these are worth being documented in some extra 
document.

4) bug reports. We do not need to collect them, since one hour 
later 96% of them are already fixed. Just search the archive if 
you have some trouble.

5) Questions regarding fonts/encodings. Yuck. I have no clue what to do 
with them. There is really something that has to be done. I know 
that there is are docs. But there are a many questions on the 
list concerning this subject.

6) request for improvements. They are probably documented in 
Hans' privat todo list... I there a need to collect them? I 
think yes.

7) Questions like "How can this feature xyz (just think of gb's 
indefinate long page that got cut off after each chapter) be 
achieved? These questions are often very esoteric. But imho they 
are worth being collected.

So what is my conclusion? Ignore some questions, improve the 
documentation where necessary, collect some stuff for an extra 
doc. We do not need an faq.

Viele Grüße,

  Patrick Gundlach

Re: suggestion

[Hans Hagen]

At 07:46 PM 1/25/2002 +0100, Frans Goddijn wrote:
> > So, you just have to find a person
>
> > p.s.: I fulfil neither criterium, I think ;-)
>
>But you are qualified to FIND that person!

since it comes down to:

-  summarize the question
-  collect the answers and make a few examples

i think that any user can do it, preferably the one who asked the question; 
that way we only need to set up the structure to collect and index them

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
-------------------------------------------------------------------------
                                   fall-back web server: 
www.pragma-pod.nl
-------------------------------------------------------------------------

Re: suggestion

[Daniel Pittman]

On Fri, 25 Jan 2002, Hans Hagen wrote:
> Does it make sense to summarize questions and answers (often more than
> one)? 

Almost certainly. I tried to find a FAQ first, myself, and read the
documentation on ConTeXt to try to understand why it wasn't working
quite right.

> Of course this should be done by the one asking the question -)

Well, here is my contribution:

* Why isn't a row in my table or tabulate being drawn correctly, but
  rather shows only the first line and cuts off the rest.

You MUST specify all of the column /and/ row markers for each row in a
table. If you fail to give the end of row marker (\NR) then the height
of the row is not correctly calculated and only a single line will be
displayed.

Er, I suspect that the question might need to be rephrased, but that's
the best I can come up with. :)

        Daniel
-- 
What is art but a way of seeing?
        -- Thomas Berger

Re: suggestion

[Frans Goddijn]

> So, you just have to find a person 

> p.s.: I fulfil neither criterium, I think ;-)

But you are qualified to FIND that person!

;=}} groet, Frans

Re: suggestion

[Eckhart Guthöhrlein]

Berend de Boer wrote:

> Hans Hagen <pragma@wxs.nl> writes:
> 
> 
>>Does it make sense to summarize questions and answers (often more than
>>one)? Of course this should be done by the one asking the question
>>-)
>>
> 
> If you have someone who can gather these summarizations and publish
> them once a month or so, you can get some FAQ after some time.
> 
> 

It would surely be very useful to have a faq. The mail archives are 
surely valuable too, but a digest would definitely make sense. So, you 
just have to find a person who is sufficiently qualified, and this 
person has to have enough spare time which he/she is willing to donate 
to the task.

Eckhart

p.s.: I fulfil neither criterium, I think ;-)

Re: suggestion

[Frans Goddijn]

I'm sure a selection of simple and practically applicable
Q&A's would be published in MAPS and these might even be
made available on a web page...

----- Original Message -----
From: Berend de Boer
To: Hans Hagen
Cc: ntg-context@ntg.nl
Sent: Friday, January 25, 2002 3:23 PM
Subject: Re: suggestion

Hans Hagen <pragma@wxs.nl> writes:

> Does it make sense to summarize questions and answers
(often more than
> one)? Of course this should be done by the one asking the
question
> -)

If you have someone who can gather these summarizations and
publish
them once a month or so, you can get some FAQ after some
time.

Re: suggestion

[Berend de Boer]

Hans Hagen <pragma@wxs.nl> writes:

> Does it make sense to summarize questions and answers (often more than
> one)? Of course this should be done by the one asking the question
> -)

If you have someone who can gather these summarizations and publish
them once a month or so, you can get some FAQ after some time.

-- 
Groetjes,

Berend. (-:

suggestion

[Hans Hagen]

Hi,

Does it make sense to summarize questions and answers (often more than 
one)? Of course this should be done by the one asking the question -)

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
-------------------------------------------------------------------------
                                   fall-back web server: 
www.pragma-pod.nl
-------------------------------------------------------------------------

suggestion

[Denis B. Roegel]

Since errors in the tex or mpost runs often go unnoticed
when using texexec, wouldn't it be possible for texexec to
look for errors in the log files and report something
at the *end* of the final run?
I just got caught because I had written `: =' instead
of `:=' in some metapost code. texexec wouldn't show it.

Denis