[pmwiki-devel] New Recipe: Content

[Martin Fick]

--- Crisses <crisses at kinhost.org> wrote:
> > - Maybe a fancy font text generator, remember the
> > 90s when people  used gifs to create custom fonts? :)
> 
> Actually, there's still a call to do something like
> this for  navigation, and headlines.  If you look at CSS Zen
> Garden, and you start dreaming a lot -- then realize PmWiki 
> can't DO that....because of a lack of font flexibility in HTML.... 
> you start thinking maybe a judicious text image spawned by 
> PmWiki here and there wouldn't be so bad. ;)

Script Fu plugin?
 
> > - An electrical circuit (schematic) illustrator
> 
> THAT would interest my partner (RF electrical engineer)

Name the program, I will embed it. :)


> visual chess board layouts from the ascii chess notation (I don't  
> know the name of it)!!  I can see Patrick doing this yesterday ;)   
> Oh, look, he already did! ;)  

Yes, I was thinking mainly an export function for that one.


> > - A class file compiler for coding java applets directly in a 
> > wiki page. eeevil ;) 
> 
> LOL
> 
> So can you embed objects with this?  

Well, you don't really need this recipe to embed objects, attachments work 
just fine for that, but if you want to generate the embedded ojects, that 
would be a good task for this recipe.  To embedd the generated objects in 
your page, all you need is the URL to it and this recipe provides a 
convenient way ot generete those ... more below...

> Because there's also some  interesting XXX->swf applications out there.  You
> can make small  flash apps on the fly (Patrick -> slideshows!!). 

I don't know what you make your swf from, but basically if you have a swf 
source type that you embedd with (:swf-src:) directives, then assuming you 
have an swf-src to swf converter you can create a URL (instead of the 
standard link) to the output with a URL like this: {$..swf}.  It looks like 
if you use Flash recipe all you would need to do output that URL and the 
flash recipe will automatically turn it into an embedded flash object since 
it will end in '.swf'.


> Someone had mentioned to me that every time PmWiki
> came up with new markup, a pdf output recipe had to be updated to
> render said markup properly in a print format...  I don't think your
> API would change  that work...but would it make it any easier?

No, I don't think so.

 
> Actually tables as an image would sometimes be
> nice.... the data  would still be there, and be searchable, I would
> think, which makes  it a presentation win/win, unlike exporting an image
> from an Illustrator/Excel/etc. graph/table.

Sure, if you have a filter that creates images out of CSV, this would be a 
snap.


> >   http://www.pmwiki.org/wiki/Cookbook/SourceBlock

> I think for this one you'd still want to be able to
> select & copy  text....creating a beautified image loses 
> some appeal for sourcecode.  Or did you mean to use this to export
> to a text-processing app, and return to the wiki as coded
> text?

I was thinking at least as just a way to provide a link to the source.  If you 
are going to go through the effort to put source code into a wiki page it 
would be nice to be able to click on a link and get just the source code in a 
file so that you can run it locally right? :)


> >   http://www.pmwiki.org/wiki/Cookbook/Comments
> Comments?

Hmm, not sure what I was thinking here. :)


> > The Network Effect
> >
> > What's interesting is that once a few converters
> > are created and various base types are defined, 
> > independent recipes should start to grow more  
> > capabilities transparently since new export types 
> > could potentially become available to them.
> 
> I don't get how changes to the base would change how
> the recipes use them.
> 
> If we add a new (:greenpigs:) markup, and someone
> updates the API so  that it throughputs (:greenpigs:) 
> how does that tell the PDF generator how to make 
> (:greenpigs:)  look on the output end?  Someone  
> would have to update the PDF renderer to display 
> (:greenpigs:) in a print format.

You have to think it terms of converters, not renderers. 
i.e., there is no pdf renderer (except for your pdf client),
but there can be converters to PDF from other formats
and from PDF to other formats.  So, if someone started
off with a greenpigs2PDF converter but someone integrated 
in another recipe a PDF2PS converter without knowing
that the greenpigs recipe even existed, greenpigs
will automatically be convertable to PS (by way of PDF).


> Now, if someone wanted to create an OGG output based on your ASCII
> music notation->midi, I could see how that might help...

Right, actually if someone integrates a midi to anything converter (and they 
are out there), then this 'anything' type would automatically become 
available from most of the music formats since the music input formats have 
there default list defined as '-ppm', (-> all available formats except for 
ppm).


> Well chess layouts are still chess layouts.  Ascii music notation
> rendered as chess layouts might be interesting (or just fail). :)  It
> might be easier to render a chessboard layout as music.

I'm not sure I understand what your are saying?  The built in converter 
indexer is smart enough to figure out that if you can get from A to B and 
from B to C that you can get from A to C, but just because you can also get 
from D to E does not mean that it will think that you can get from A to E! ;)
The network effect is due to a potential fan out/in, with the following 6 
converters:

  A -> B
  B -> C
  D -> E
  T -> S
  X -> Y
  Y -> Z

You get a graph like this:

  A -> B -> C
  D -> E
  T -> S
  X -> Y -> Z

which means you actually have 8 converters

  A -> B
  A -> C
  B -> C
  D -> E
  T -> S
  X -> Y
  X -> Z
  Y -> Z


Add the following 3 converters: C -> D, D -> S and Z -> C, now your graph 
looks like this:

  A -> B -> C -> D -> E
                            -> S -> T
  X -> Y -> Z -> C -> D -> E
                                   -> S -> T

which leads to the following 30! converters:

  A -> B
  A -> C
  A -> D
  A -> E
  A -> S
  A -> T
  B -> C
  B -> D
  B -> E
  B -> S
  B -> T
  C -> D
  C -> E
  C -> S
  C -> T
  D -> E
  T -> S
  X -> Y
  X -> Z
  X -> C
  X -> D
  X -> E
  X -> S
  X -> T
  Y -> Z
  Y -> C
  Y -> D
  Y -> E
  Y -> S
  Y -> T

That's what I mean by network effect! :)  In fact I'm scared that if this 
recipe takes off that the indexing will quickly get out of hand.

> I actually love the idea of adding this capability, because I've been
> doing a lot of data work.  Data->CSV alone is doable by pagelist with
> templates, but then you have to cut&paste it into a document.  Having
> another way to do it, with a downloadable, would be great.

If you let me know a little more what you're thinking here, I will gladly help 
make use of the API!


-Martin