[PD-dev] pddp style guide

Hans-Christoph Steiner hans at eds.org
Thu May 5 01:41:14 CEST 2005

I think #1 (fonts) is solvable without too much work.  Nobody taken a  
stab at it in the recent past AFAIK.

#2 (comment formatting) already exists in two formats: the fixed width  
PDDP style using Pd "text" objects, and Krzysztof's [comment] from  
cyclone.  If [comment] had a bit more interface polish, it'd be quite  
usable for PDDP.


On May 4, 2005, at 3:24 PM, B. Bogart wrote:

> Hi Krzysztof,
> Indeed PDDP is a great resource, and I'm exited to contribute to it.
> I also agree that we should discuss PDDP before jumping in with new
> content, this means having templates and working on the style-guide.
> I don't see why both html and ps/pdf were chosen here, since they are
> both fairly equal when it comes to formatting text on a page. PDFs can
> be generated from HTML as well PDFs could be generated from PD help
> patches via the "print" feature and a little ghostscript (Mathieu
> mentioned making a stand-alone script that generated PS files directly
> from patches.)
> I can't agree that having the bulk of PD content (documentation) in the
> PD patch format is a bad idea. What are the limitations/problems with
> the format that makes this a bad idea? I see two:
> 1. The inconsistant fonts over different platforms
> 2. limitations in controlling the look of "comments" or text in general
> in a PD patch. If comments could justified, change fonts, and change  
> the
> wrapping width it would work pretty well for documentation. Or comment
> could stay as-is and a new form of [text] could be created.
> As for 1, I don't know how to fix this, but it makes consistant
> documentation a real pain, this needs to be resolved. Once #1 is fixed  
> I
> don't think 2. is really needed, as PDDP templates would simply conform
> to the width of comment boxes. #2 is probably much more work than #1.
> As I have said above I don't think there are any real significant  
> issues
> with "printing" PD patches as PS and distributing as PDF.
> From a teaching point-of-view an interactive patch will get the idea
> accross much faster than an html document explaining a certain concept
> in words.
> Personally I think time would be better spent making PD patches work as
> good documentation (the patcher is just a vector layout anyway), than
> embedding html/pdf reading facilities into PD. The benifits (to a  
> person
> learning PD) of a patch as documentation outweigh the benifits of  
> having
> the ability to load html files along-side patches in PD.
> Thats my opinion anyhow.
> b<
> Krzysztof Czaja wrote:
>> hi Hans-Christoph,
>> firstly -- I am very grateful for yours and Dave's work.
>> Secondly, imho it is better to rethink pddp now, before adding
>> new contents.  The original idea was that pddp should provide
>> a consistent framework for at least three kinds of media:
>> patches, html, and ps/pdf.  The choice then was to either
>> base it on docbook, or to design a very simple custom format.
>> The latter never materialized, and certainly never will.  Hardly
>> being a docbook fan myself, I do not see any alternative...
>> Anyway, the worst thing that could happen, would be having all
>> the reference pages, and ``more info'' propaganda embedded in Pd
>> comments.  There would be no other way of putting those on
>> other media, than many days of hard manual work.  The likely
>> result of which would be forking of the pddp source.
>> Let us use patches as patches, and comments as comments.
>> A tricky part, besides tailoring docbook styles, is deciding about
>> a mechanism for opening patches in Pd by invoking links in a html
>> browser.  The easiest way is including a simple httpd server in
>> pd-gui.  There is a ready to use 250-liner at
>> http://cvs.sourceforge.net/viewcvs.py/tclhttpd/tclhttpd/bin/mini/
>> Krzysztof
>> Hans-Christoph Steiner wrote:
>> ...
>>> If anyone is interested, it'd be great if we could work together to
>>> create the style guides. The way I currently see it there are two
>>> kinds of patches "all_about_" which has lots of text and examples,  
>>> and
>>> the basic help patch, which should be a reference with a link to the
>>> relevant "all_about_" pages. float-help.pd from PDDP is a decent
>>> example of a reference patch.
>> _______________________________________________
>> PD-dev mailing list
>> PD-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev


"Information wants to be free."
                              -Stewart Brand
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2353 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20050504/dd35262a/attachment.bin>

More information about the Pd-dev mailing list