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?).
B.
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:
- The inconsistant fonts over different platforms
- 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@iem.at http://lists.puredata.info/listinfo/pd-dev
"Information wants to be free." -Stewart Brand
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev