[PD-dev] pddp style guide

B. Bogart ben at ekran.org
Thu May 5 17:14:28 CEST 2005

Hi HC,

Nice to hear confidence about #1. I'm still a little unclear about the
problem, is it that font size "12" on platform A is many more pixels
high than font size "12" on platform B? In which case can we do some
math so that the font size "12" is actually "13" on platform B so that
it matches platform A?

#2: The comment width is only as fixed as the font width correct? So the
paragraph grows wider depending on platform, and I guess the biggest
font wins and the smallest loses. I did see Krzysztof's comment which
does look quite nice (non-courier!) I see this issue as being somewhat
separate from the documentation issue. #2 does not help, but it just
need a little polish. Somehow I don't see it being fixed anytime soon. I
have not looked at the tk commands for text on canvases, not sure things
like a wrapping box can be specified. I'll have to peek at Krzysztof's
source to see how he got it working (embeded entry widget?).


Hans-Christoph Steiner wrote:
> 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.
> .hc
> 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
> ------------------------------------------------------------------------
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20050505/31726bb7/attachment.pgp>

More information about the Pd-dev mailing list