Hi @TiddlyTweeter, Jan, et al, 1 - The question of HARD-CODING v. coding that enables ANY system of markup > to be used at will. > > Yes -- that's why I posted here -- avoiding those issues ;-)
> 5 - I guess what I am getting at is a more GENERIC process that utilises > RegEx via a global macro (limited to a new Tiddler type to prevent it > "eating-my-wiki"?) > > A macro? I can imagine a macro that you pass your text and your RegEx rules and it outputs HTML-ized text that you then modify with CSS. Is that better or worse than a parser (or pseudo parser) that allows you to see the effect of your text in the preview window as you work? My MAIN point is I DO NOT think this is about yet another fixed, > hard-encoded markup. Though being able to generate schema that appear > hard-coded could be a big plus? Maybe I'm an idiot? :-) > But this thread was. At least at the start. Sometimes it's easiest to start with specifics and then work your way outwards. One of the minor issues *with both WikiText markup & Fountain markup* (!, > @, # etc) is that you can't just pass it to CSS because CSS class names > only accept alpha-numerics. Its not a big deal but its not as easy as > using, say, start of line markers like this .... > > > > * :s = scene :a = act* > > Elaborate. I'm not sure what you mean by "pass it to CSS". If "markup" were in the form (start of line) ... > > > *:a* > or > *:aa* > > What would the expected output of these markup tokens be? Would they be line-based, or apply to the entire MSS ? Fountain markup is oriented to WHOLE SCRIPTS. It has NO CONCEPT of what *WE* > do, which is to be able to work "from FRAGMENTS to WHOLES". > > Some of the things that be-devil Fountain *we* can probably solve, > eventually (after sweat), much better. > > *Like WHAT IS A PAGE? * > > Fountain hard-codes pages as its only method. *That is unworkable* until > you have finished writing your script (unless you are an expert at counting > 57 lines BEFORE rendering---i.e. figure out how everything will > wrap--impossible). > > But PAGE NUMBERS are very important in movie scripts (because 1 page = 1 > minute of film). They need to be DYNAMICALLY calculated whilst WRITING so > you know WHAT timing you have. > My assumption is that something like Fountain is useful to help a writer see how their formatting is shaping up as they work. TW shines at allowing an author to write bits and pieces of a work at a time distraction-free and then aggregating the material further down the road. I don't understand how pages can be dynamically calculated to be 1min=1page, since a single direction item might take up more than a minute. In any event, I would think that the final pagination would best be handled in an application designed for that task. I'm really skeptical of getting browser-based automatic pagination to work. Is there a precedent? But IF you do excess formatting, not in the conservative standard, its used > as a reason to dump your application. > So this explains why, with 50,000 new scripts submitted every year, we keep getting Batman and Spiderman origination stories -- they were the only ones with the properly formatted scripts! Let me explain about the way parsing works in TW. With standard parsing, it's not a matter of simple regular expression replacement. What happens is that regular expressions are used to prise out bits of string from the working text. The strings are analyzed by code logic and then used to build up a JSON-like internal tree. The HTML/iframe approach I used was much simpler, because all I had to do was pass the frame the Markup text converted by Fountain.js to HTML (plus a little CSS up front). If the results of that approach are adequate (e.g. you don't hate iframe rendering) then I can imagine a more universal syntax approach. Maybe the top of the page would have instructions: #REG/\.s\s(.+)$/<div class="something">\1</div> > #REG/\.r\s(.+)$/<div class="somethingelse">\2</div> > #REGG/something-i-want-to-replace-globally/<p class=yipes>\1</p> > I haven't worked out the full syntax obviously. It would be something like Skeeve's pragma thing, but without the controversy since we're not trying the really complicated approach of modifying the parser (which is still something like voodoo magic to me). All for now, Mark -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/99be306a-0a1d-41f2-bae1-6f9aef559a4d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
