Richard Koch wrote:
> this all is need, super and thanx walter, - but any chance to get the html help as a printable pdf or like wise?

I have no experience with creating pdf's, I have no idea what is involved. Frank is looking at creating Latex output.

There are libraries, like pdflib.  I've worked with that one, but I think there are others.

A quick Google found me:

http://www.rustyparts.com/pdf.php
http://www.tufat.com/script19.htm

And if the data could be semantically parsed, it wouldn't be hard to just write it out using pdflib and not have the header/footer.  But maybe it's easier to use an existing tool like the above.

That said, I wouldn't personally prefer a pdf.  I'd prefer a chm, if anything, since that can be integrated into various editors... and I'm told there are Linux CHM viewers (but don't know personally since I only use Linux for servers.)

CHMs are also easy.  They're like zip files of html, with an index. It's a little more complicated, but not much.

-[Unknown]


> Richard Koch wrote:
>> this all is need, super and thanx walter, - but any chance to get the html help as a printable pdf or like wise?
> 
> I have no experience with creating pdf's, I have no idea what is involved. Frank is looking at creating Latex output.

Walter Bright wrote:

>> this all is need, super and thanx walter, - but any chance to get the html help as a printable pdf or like wise?
> 
> I have no experience with creating pdf's, I have no idea what is involved. Frank is looking at creating Latex output.

I posted a script that created PDF from the HTML using "htmldoc",
and the output wasn't exactly pretty - but readable and printable.

http://www.easysw.com/htmldoc/

Haven't tried it with the updated documentation though, and it was
over 350 pages long so I guess you would have to have a good printer :-)

Ddoc probably needs some PDF output capabilities... ?

--anders

Walter Bright wrote:
> kris wrote:
>>  ... get a flat-panel that can be rotated into portrait mode. The 24" Dell displays more lines of code (in portrait orientation) than you can shake a stick at :)
> 
> There's never enough screen real estate (but I now can't imagine working on 24 line displays like I used to).

Amen. I used to print my source code out and do most of my programming on paper, partly for that reason.
Actually, I think that's what most of the {} formatting wars are about. Anyone who feels their screen isn't big enough is never going to be happy with one of the styles that uses lots of vertical space.

Kris, with your coding style, I always suspected your screen was much bigger than mine <g>.

Don Clugston wrote:
> Walter Bright wrote:
> 
>> kris wrote:
>>
>>>  ... get a flat-panel that can be rotated into portrait mode. The 24" Dell displays more lines of code (in portrait orientation) than you can shake a stick at :)
>>
>>
>> There's never enough screen real estate (but I now can't imagine working on 24 line displays like I used to).
> 
> 
> Amen. I used to print my source code out and do most of my programming on paper, partly for that reason.
> Actually, I think that's what most of the {} formatting wars are about. Anyone who feels their screen isn't big enough is never going to be happy with one of the styles that uses lots of vertical space.
> 
> Kris, with your coding style, I always suspected your screen was much bigger than mine <g>.

*blush*

It's funny, but that style was initially adopted on a vt52. Old habits die hard.

Years later (1989) when I convinced a corporation to splash out on /secondary/ monitors with *gasp* a full-length Hercules card supporting 50 lines of text, the engineering team bought me beers for weeks afterward. Those were appreciated more than stock options :)

Walter Bright wrote:
> Bruno Medeiros wrote:
>> Walter Bright wrote:
>>>
>>> http://thc.segfault.net/root/phun/unmaintain.html
>>>  From - Mon
>>
>> Speaking of which (but seriously), we may not get a consensus on tabs, and maybe justifiedly so, but one other thing with DMD's coding convention that troubles me is the braces formatting:
>>
>>     if (b)
>>     {    dg();
>>          return true;
>>     }
>>
>> ... whoa :/ . Where did that come from? It's unusual (I personally have never seen C-family code formatted that way), and seems awkward to me. 
> 
> It's just:
> 
>     if (b)
>     {
>        dg();
>        return true;
>     }
> 
> compressed to save precious vertical screen space.

Then how about K&R style?

Walter Bright schrieb:
> Richard Koch wrote:
>> this all is need, super and thanx walter, - but any chance to get the html help as a printable pdf or like wise?
> 
> I have no experience with creating pdf's, I have no idea what is involved. Frank is looking at creating Latex output.

I don't have the time atm, but if we had XML-DDoc i could easily write a CHM and a PDF Export which could then be customized.
I already had PDF output: I wrote an XML output for DDoc, which was then formatted with Apache FOP and a decent XSL-FO Stylesheet. But i didn't maintain it as i'm stuck knee-deep in some other projects.

Bruno Medeiros wrote:
> Walter Bright wrote:
>>
>> http://thc.segfault.net/root/phun/unmaintain.html
>>  From - Mon
> 
> Speaking of which (but seriously), we may not get a consensus on tabs, and maybe justifiedly so, but one other thing with DMD's coding convention that troubles me is the braces formatting:
> 
>     if (b)
>     {    dg();
>     return true;
>     }
> 
> ...
> ?

My personal preference is:
     if (b)
     {    dg();
          return true;
     }
with all the indentations managed by tabs, so you can decide how much indenting you find useful.  (I normally choose 3 spaces...but there are times when I compress it down to two, and I used to usually use 4 spaces.)

I'd be surprised if this was the most common choice, however.

On Wed, 23 Aug 2006 04:41:01 +0300, Charles D Hixson <charleshixsn@earthlink.net> wrote:

> Bruno Medeiros wrote:
>> Walter Bright wrote:
>>>
>>> http://thc.segfault.net/root/phun/unmaintain.html
>>>  From - Mon
>>  Speaking of which (but seriously), we may not get a consensus on tabs, and maybe justifiedly so, but one other thing with DMD's coding convention that troubles me is the braces formatting:
>>      if (b)
>>     {    dg();
>>     return true;
>>     }
>>  ...
>> ?
>
> My personal preference is:
>       if (b)
>       {    dg();
>            return true;
>       }
> with all the indentations managed by tabs, so you can decide how much indenting you find useful.  (I normally choose 3 spaces...but there are times when I compress it down to two, and I used to usually use 4 spaces.)
>
> I'd be surprised if this was the most common choice, however.

That one I haven't seen yet. :)


Well, if you like to see an uncommon case (I think), here's a one, heheh. It's the one I prefer:

if(b) {
    dg();
    return true;
    }


Before you feel sorry for me, there is a point for using it, and it is cases where you don't use brackets.
For example, compare the following cases:

//case 1
if(b) {
    doX();
    doY();
    }
else {
    doY();
    doZ();
    }

//case 2
if(b)
    doX();
else
    doY();

//case 1 + 2
if(b) {
    doX();
    doY();
    }
else
    doY();

See how similar the cases are, and how they fit together. Indention tells where a block or single line statement starts. And where it ends, you may ask? Well, of course, it ends before the next one starts. (Code will look like there were a caption and paragraph(s), a caption and paragraph(s), etc.)

I know any syntax can look weird, until you get accustomed to it. And you can get accustomed to a lot of things.

Kristian wrote:
> On Wed, 23 Aug 2006 04:41:01 +0300, Charles D Hixson <charleshixsn@earthlink.net> wrote:
> 
>> Bruno Medeiros wrote:
>>> Walter Bright wrote:
>>>>
>>>> ...
> 
> Well, if you like to see an uncommon case (I think), here's a one, heheh. It's the one I prefer:
> 
> if(b) {
>     dg();
>     return true;
>     }
> 
> 
> Before you feel sorry for me, there is a point for using it, and it is ...
I don't feel sorry for you.  I consider it largely a matter of taste (though I couldn't use yours).  The point of my system is "brackets should line up vertically!".  I'll admit, however, that I can't quite figure out how switch/case statements should be handled using my preferred approach.
I dither between at least two choices.  (Partially because I don't use them very often.