BCS wrote:
> Walter Bright wrote:
>>
>>
>> Just pick one or two of the files to develop the technique. Once that
>> works, we can fix the rest.
> file:///home/urxae/tmp/ddoc_tex/tex.ddoc
>
> Here is the first attack
>
>
> PDFs here:
>
> http://www.webpages.uidaho.edu/~shro8822/type.pdf
>
> The table environment is proving hard to deal with. Also, it's looking
> like Ddoc is going to need some sort of find-and-replace for escaping
> special strings (think SED).
>
> and here:
>
> http://www.webpages.uidaho.edu/~shro8822/glossary.pdf

I've been messing around with this a bit. Attached you'll find an
updated tex.ddoc. Tables are now actually tables (not just a giant blob
of text :)), and section headers are now properly in \section and
\subsection.
The table handling is far from perfect, though; columns are hard-coded
to a maximum of 3 colums, each 5cm wide.

Does anyone know how to get HTML-like auto-wrapping cells in latex,
without having to explicitly specify their width? Or is this not possible?

By the way, there's a missing '$' in the ulong row of the table at the top of type.d. Walter Bright wrote: > BCS wrote: >> Here is the first attack > > It's a good start. If you can write up the roadblocks you're > encountering, I can try and figure out a way to deal with them. Well, it might be handy to have a way to repeat a character N times, with N given by a macro parameter. Then the table macro could accept a number-of-columns argument, generalizing it to any number of columns.  Walter Bright wrote: > BCS wrote: > >> Here is the first attack > > > It's a good start. If you can write up the roadblocks you're > encountering, I can try and figure out a way to deal with them. The problem for tables is that TeX defines tables sizes with a syntax like this \begin{table}[llll] % a table with 4 col. .... \end{table} the string that needs to be inserted into the template is the sequence of "l", for which there needs to be one for each col. Some sort of translation from "4" to "llll" is needed. --- My first thought on how to do this is to to have a few special case macros that are implemented inside the compiler. For instance the "4" -> "llll" mapping would be easy to do in D: "$(REPEAT_STRING l 4)" ==> repeat_string(["l", "4"]) ==> "llll"

char[] repeat_string(char[][] args)
{
int l = args[0].length;
int c = atoi(args[1]);
char[] ret = new char[l*c];
for(int i=0; i<c; i++)
ret[i*l..(i+1)*l] = args[0];
return ret;
}

-------

Another problem that comes up is the need to escape special character
sequences. Some sort of sed like rule that would be applied to all raw
text from the input file would be quite adequate.

source.d:
$(BF hello_world$(SUB earth))

tex.ddoc:
SUB=_{$0} BF={\bf$0}
s/_/\_/

output.tex:
{\bf hello\_world _{earth}}

-------

Another problem that showed up (cosmetic in this case) was that in some
cases the text inside of a macro ended in a \n and caused things to look
something like this:

foo(); {\color{green} // comment1
} bar(); {\color{green} // comment2
}

rather than the preferred:

foo(); {\color{green} // comment1}
bar(); {\color{green} // comment2}

It would be nice to be able to isolate the end of the string if it is a
newline. An off-the-cuff solution would be to have "$-" or some such be any and all trailing newlines. Then something like this could be used: COMMENT=$(GREEN $0)$-

However this would require that either those newlines be striped from $0 when$- is used, or that a form of $0 be created that always does the stripping (maybe$-0)

Frits van Bommel wrote:
>
> Tables are now actually tables (not just a giant blob
> of text :)),

I just didn't bother because I couldn't to it "right".

> and section headers are now properly in \section and
> \subsection.

Thanks.

OTOH maybe the whole things should be a chapter and imported/include
from some other document. The whole thing could then be done as a book.
Whatever, that's would just be another tex_book.ddoc file.

[...]
> By the way, there's a missing '\$' in the ulong row of the table at the
> top of type.d.
>

oops.

Maybe there should be a dsource project for DDoc macro sets?

BCS wrote:
> Walter Bright wrote:
>> BCS wrote:
>>
>>> Here is the first attack
>>
>>
>> It's a good start. If you can write up the roadblocks you're
>> encountering, I can try and figure out a way to deal with them.
>
>
> The problem for tables is that TeX defines tables sizes with a syntax
> like this
>
> \begin{table}[llll]
>     % a table with 4 col.
>     ....
> \end{table}
>
> the string that needs to be inserted into the template is the sequence
> of "l", for which there needs to be one for each col. Some sort of
> translation from "4" to "llll" is needed.

I'm pretty certain you could write a TeX macro to do that.  Don't ask me
how though.  :-)  Then DDoc macro would spit out something like
\some_els{4}, which would then be processed by a LaTeX macro into 'llll'.

Supposedly TeX is a Turing complete programming language, so it should
be possible.  Just maybe not fun.

But in the end it would probably easier to have ddoc spit out some sort
of meta-TeX, and use a perl/python/ruby/D script to grep through the
result for special commands.

I.e. you could have the DDoc macro spit out

\begin{table}[@@@'l'*4@@@]
...
\end{table}

And use python/perl to grep for all @@@...@@@ patterns and run eval() on
the text it finds there.

Of course I understand the desire to make DDoc capable of doing this on
its own, but DDoc macros will probably never be a full-fledged
programming language, so at some point you just have to give up and use
something that is.  In fact you could argue that going DDoc->TeX->pdf is
already such a situation.  Why not DDoc->ScriptyLanguage->TeX->pdf?

--bb

BCS wrote:
> Frits van Bommel wrote:
>>
>> and section headers are now properly in \section and \subsection.
>
> Thanks.

The loose word at the top with a trailing comma was just too ugly to let
it stand, and it was an easy fix...

> OTOH maybe the whole things should be a chapter and imported/include
> from some other document. The whole thing could then be done as a book.
> Whatever, that's would just be another tex_book.ddoc file.

Yeah, maybe that's better. I didn't do that mostly because it was
already \documentclass{article} and I'm lazy ;).
Anyway, it'd be easy to fix, just change the document class to book,
s/section/chapter/, s/subsection/section/ and probably add a title page

> Maybe there should be a dsource project for DDoc macro sets?

Perhaps, if there's enough interest.
Personally, it just bothered me that there was such a huge block of text
that should've been a table, so I 'fixed' it. I think I probably won't
be contributing a lot to this project, since I'm perfectly OK with HTML
docs...

Bill Baxter wrote:
> BCS wrote:
>> The problem for tables is that TeX defines tables sizes with a syntax
>> like this
>>
>> \begin{table}[llll]
>>     % a table with 4 col.
>>     ....
>> \end{table}
>>
>> the string that needs to be inserted into the template is the sequence
>> of "l", for which there needs to be one for each col. Some sort of
>> translation from "4" to "llll" is needed.
>
> I'm pretty certain you could write a TeX macro to do that.  Don't ask me
> how though.  :-)  Then DDoc macro would spit out something like
> \some_els{4}, which would then be processed by a LaTeX macro into 'llll'.

Ooh, using TeX instead of DDoc for this is something I hadn't
considered. Too bad I suck at TeX beyond basic markup :(.

> Supposedly TeX is a Turing complete programming language, so it should
> be possible.  Just maybe not fun.

It only needs to be done once though...
Any TeX gurus in this newsgroup?

Frits van Bommel wrote:
> Bill Baxter wrote:
>> BCS wrote:
>>> The problem for tables is that TeX defines tables sizes with a syntax
>>> like this
>>>
>>> \begin{table}[llll]
>>>     % a table with 4 col.
>>>     ....
>>> \end{table}
>>>
>>> the string that needs to be inserted into the template is the
>>> sequence of "l", for which there needs to be one for each col. Some
>>> sort of translation from "4" to "llll" is needed.
>>
>> I'm pretty certain you could write a TeX macro to do that.  Don't ask
>> me how though.  :-)  Then DDoc macro would spit out something like
>> \some_els{4}, which would then be processed by a LaTeX macro into 'llll'.
>
> Ooh, using TeX instead of DDoc for this is something I hadn't
> considered. Too bad I suck at TeX beyond basic markup :(.
>
>> Supposedly TeX is a Turing complete programming language, so it should
>> be possible.  Just maybe not fun.
>
> It only needs to be done once though...
> Any TeX gurus in this newsgroup?

I spent a few minutes searching the web (yet again) for decent
documentation on writing TeX/LaTeX macros, and (yet again) came up with
nothing useful.  The only book I have (Lamport's LaTeX book) is also
similarly useless.

That's why I say it may be easier in the end to just go to an external
language.  At least I know I could whip up something in Python that
would take me less time to do that getting that one dumb macro working
in TeX.  :-)

--bb

> I'm pretty certain you could write a TeX macro to do that.

This should do the trick:
\def\replicate#1#2{\ifnum#1>0 #2%
\expandafter\replicate\expandafter{\number\numexpr#1-1}{#2}\fi}

Used as \replicate{4}{l}. I found this snippet - written by David Kastrup
- in "Pearls of TEX Programming" (2005).

Christian

> Does anyone know how to get HTML-like auto-wrapping cells in latex,
> without having to explicitly specify their width? Or is this not
> possible?

The tabularx package might do what you want:
http://www.cs.ualberta.ca/~c603/latex/tabularx.pdf

It requires specifying the width of the table on creation, but adds the
column-type 'X' that automatically expands to the maximum width.

Christian

Christian Kamm wrote:
>> Does anyone know how to get HTML-like auto-wrapping cells in latex,
>> without having to explicitly specify their width? Or is this not
>> possible?
>
> The tabularx package might do what you want:
> http://www.cs.ualberta.ca/~c603/latex/tabularx.pdf
>
> It requires specifying the width of the table on creation, but adds the
> column-type 'X' that automatically expands to the maximum width.

Unfortunately, it seems to default[1] to all 'X' columns having the same
width. This looks kind of bad with the table in types.d, where the first
column contains things like 'void', 'int' and 'float', and the other two
columns contain somewhat longer texts...

Another problem is that this doesn't play nice with your other
suggestion: a \replicate in the second argument of tabularx yields the
message "! Package array Error:  Illegal pream-token (\replicate): c'
used." and no output file :(.
Is there any way to expand this before it's seen by the tabularx
environment?

[1]: It's seems that it's possible to specify the relative widths, but
that's also problematic as DDoc doesn't know what they should be, so
using that would probably require yet another extra parameter to the macro.
`
1 2 3