[PD-dev] pddp style guide
ben at ekran.org
Thu May 5 17:14:28 CEST 2005
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.
> 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.
>> 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
>>> 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
> "Information wants to be free."
> -Stewart Brand
> PD-dev mailing list
> PD-dev at iem.at
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 256 bytes
Desc: OpenPGP digital signature
More information about the Pd-dev