cl-pdf meets cells?
Kenny Tilton
might even benefit the mother company, so....
/if/ i was going to do a layout mechanism for pdf, should it be via
mark-up? actually, i am thinking a combination of macros for high-level
layout plus markup to handle large blocks of text, mainly font and
styling stuff in there, forced page breaks...
and if i am going with markup, should i just use html? tex? xml? other?
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"Be the ball...be the ball...you're not being the ball, Danny."
- Ty, Caddy Shack
Fernando Rodríguez
>otay, not saying i am actually going to do this, but I can see how it
>might even benefit the mother company, so....
>
>/if/ i was going to do a layout mechanism for pdf, should it be via
Why PDF? I think it would better to output a generic layout specification and
then write functions that traverse this data-struc and 'compile' it to a
specific layout format: PDF, windows metafiles, rtf, whatever you need. This
way you can start with cl-pdf (if that's what you currently need) while
letting other people add the 'compiler' functions they need.
>mark-up? actually, i am thinking a combination of macros for high-level
>layout plus markup to handle large blocks of text, mainly font and
>styling stuff in there, forced page breaks...
>
>and if i am going with markup, should i just use html? tex? xml? other?
I think this is a good idea, but I wouldn't use html, tex or anything like
that. This would force you to write a parser when there's NO need for it: use
Lisp and you get the parser for free. :-)
Make sure that these 'low-level' format specifications aren't too low-level,
otherwise you'll get in trouble when creating long docs that must have a
coherent format. For example, instead of specifying 'bold, red foreground and
yellow background' it should specify a style called 'warning'.
(warning "Don't code in Perl or else...")
The 'style-sheet' can be specified as a lisp data structure that is
interpreted by the 'compiling' functions.
So, the data structure that represents the generic layout will probably be a
tree and the text would be the leaves. Instead of making the leaves simple
strings or strings with markup such as "lisp <em>rules</em>", make them
text-generator objects.
The simplest text-generator would just output the given text as is, while
others could apply a style inconditionally or according to a given cosntraint.
You could implement this as a class hierarchy or as a Cell with different
constraints (including the no-constraint constraint :-).
For example: Apply a forced page break if blah, blah, blah...
I'm now reading Sonya Keene's book and it has some info about Concordia
(Symbolics text processing app) and how CLOS was used to implement it. You
might find it inspiring. :-)
----
Fernando Rodríguez
frr at wanadoo dot es
-------
Kenny Tilton
"Fernando Rodríguez" wrote:
> I think this is a good idea, but I wouldn't use html, tex or anything like
> that. This would force you to write a parser when there's NO need for it: use
> Lisp and you get the parser for free. :-)
So we have:
(normal nl (b "Q: ") "Why not use lisp and get a parser for free?"
(nl 2) (b "A: ") (i "You mean like " (ul "this") "?!")) " :)")
instead of:
"<b>Q: </b> Why not use lisp and get a parser for free?
<b>A: </b> <i> You mean like <ul>this</ul>?!"</i> :)"
?
Sure, I'm a Lisper, I dig parens and appreciate how much easier they
make editing, since one tends to move text around in related chunks and
the parens make that... tho I suppose as long as one is parsing the HTML
one could teach an editor to do the same with <x>...</x>. Anyway, the
first approach was my first instinct, I just did not think anyone like
to edit a thesis like that. But the HTML does not look like much fun
either. Of course I am being drawn onto a slippery slope in which I end
up having to do an open CL GUI so we can have a wsyiwyg editor. :)
getting back to:
> Why PDF? I think it would better to output a generic layout specification and
> then write functions that traverse this data-struc and 'compile' it to a
> specific layout format: PDF, windows metafiles, rtf, whatever you need. This
> way you can start with cl-pdf (if that's what you currently need) while
> letting other people add the 'compiler' functions they need.
yes, that is what I had in mind, and much the way our system works now
(the only reason I think I can squeeze this in). A cell-constrained
structure is traversed and "painted" to a stream, which can be an OS
window or EMF file. Other traversals do other interesting things with
the same structure. I had for a while specified that all such traversals
be handled by one recursive paint function where all variability between
targets was to be handled by specializing on the output stream, but then
I decided the traversal bit per se added so little there was no need to
bend ourselves out of shape to achieve that uniformity.
> Make sure that these 'low-level' format specifications aren't too low-level,
> otherwise you'll get in trouble when creating long docs that must have a
> coherent format. For example, instead of specifying 'bold, red foreground and
> yellow background' it should specify a style called 'warning'.
The system includes stylesheets, so:
(style warning :fg red :bg yellow)
then later:
(warning "Red on yellow?! Yechh")
where any unrecognized directive is a style...or do we get into macros?:
(macro (warning msg) `(bg yellow (fg red ,msg)))
?
>
> I'm now reading Sonya Keene's book and it has some info about Concordia
> (Symbolics text processing app) and how CLOS was used to implement it. You
> might find it inspiring. :-)
Hmm, lost my copy. I really should have one on hand. Thx for the tip.
--
kenny tilton
clinisys, inc
--------------------------------------------
"You're not being the ball, Danny."
- Ty, Caddy Shack
Fernando Rodríguez
>Reversing things:
>
>"Fernando Rodríguez" wrote:
>> I think this is a good idea, but I wouldn't use html, tex or anything like
>> that. This would force you to write a parser when there's NO need for it: use
>> Lisp and you get the parser for free. :-)
>
>So we have:
>
> (normal nl (b "Q: ") "Why not use lisp and get a parser for free?"
> (nl 2) (b "A: ") (i "You mean like " (ul "this") "?!")) " :)")
>
>instead of:
>
>"<b>Q: </b> Why not use lisp and get a parser for free?
>
><b>A: </b> <i> You mean like <ul>this</ul>?!"</i> :)"
>
>?
To reduce the number of markup characters you could use a sexp interpolation
macro, similar to the variable interpolation feature of tcl:
(setq the-true-faith "Lisp")
(sexp-interp
"Use the-true-faith to (em markup) text")
Assuming you have a em macro and hte output is hmtl, that should give you:
Use Lisp to <em>markup</em> text.
To make it more typist-friendly, you could make newlines significant and
perhaps recognize some 'macro' characters:
_important_ -> apply style emphasis to the word important
etc..
You would need a parser for this though...
I think the authors of Mzscheme did something like that. I think they had two
macros called the red-box and the black-box (or something like that).
Everything inside the red-box was considered text, and everything inside a
black-box was scheme code. You could nest red-boxes inside black-boxes and
vice-versa.
Erik Naggum
| So we have:
|
| (normal nl (b "Q: ") "Why not use lisp and get a parser for free?"
| (nl 2) (b "A: ") (i "You mean like " (ul "this") "?!")) " :)")
|
| instead of:
|
| "<b>Q: </b> Why not use lisp and get a parser for free?
|
| <b>A: </b> <i> You mean like <ul>this</ul>?!"</i> :)"
|
| ?
You asked for an alterntive some time ago, but I have yet to finish the
"schema" part of my proposal (it is so _unnecessary_), but I would write
<macro <q data>
<inline <nl> <b Q:\ > <use data> <nl>>>
<macro <a data>
<inline <nl> <b A:\ > <use data> <nl>>>
<q Why not use Lisp and get a parser for free?>
<a You mean like <ul this>?!>
Today, anyway, it might be different tomorrow. The \ before the blank is
necessary because only intraword whitespace is retained, all whitespace
between < and the operator and the operator and the first payload datum
and the last payload datum and > are ignored as syntax (markup).
| The system includes stylesheets, so:
|
| (style warning :fg red :bg yellow)
|
| then later:
|
| (warning "Red on yellow?! Yechh")
|
| where any unrecognized directive is a style...or do we get into macros?:
|
| (macro (warning msg) `(bg yellow (fg red ,msg)))
|
| ?
FWIW, I think this last example is an indicatation why some people
believe in attributes. I do not, so I would write
<macro <warning data>
<inline <color <bg yellow> <fg red> <use data>>>>
Whatever.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Thomas F. Burdick
> otay, not saying i am actually going to do this, but I can see how it
> might even benefit the mother company, so....
>
> /if/ i was going to do a layout mechanism for pdf, should it be via
> mark-up? actually, i am thinking a combination of macros for high-level
> layout plus markup to handle large blocks of text, mainly font and
> styling stuff in there, forced page breaks...
>
> and if i am going with markup, should i just use html? tex? xml? other?
I'm not sure I understand what you want to do with this (hypothetical)
project. Is this something in the vague area of TeX? Ie, for humans
who want to write their theses and have the macine lay them out? Or
is it for programs that want to spit out their output in a nicely
layed-out fashion? Or for on-screen GUI stuff? Or is for a system
that can handle all three?
For the problem domain of TeX, I'd look long and hard at TeX itself,
both on the outside and the inside. The problem isn't solved
perfectly, by any means, but I've yet to see any other piece of
software that does it as well -- hell, I've yet to see one that does
it more than half as well. Which is not to say we don't need another
TeX implementation, especially an extensible (on the inside) one in
Lisp.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Fernando Rodríguez
>"Fernando Rodríguez" wrote:
>> I think this is a good idea, but I wouldn't use html, tex or anything like
>> that. This would force you to write a parser when there's NO need for it: use
>> Lisp and you get the parser for free. :-)
>
>So we have:
>
> (normal nl (b "Q: ") "Why not use lisp and get a parser for free?"
> (nl 2) (b "A: ") (i "You mean like " (ul "this") "?!")) " :)")
I don't think I'd like to type like this... There must be a better way. O:-)
>first approach was my first instinct, I just did not think anyone like
>to edit a thesis like that. But the HTML does not look like much fun
>either. Of course I am being drawn onto a slippery slope in which I end
>up having to do an open CL GUI so we can have a wsyiwyg editor. :)
OK, so if you are expecting people to type long texts with this system, maybe
you should just reuse some existing wysiwyg editor. For example
<asbestos-underwear>MS Word</asbestos-underwear>. :-)
I've seen a system for indexing journal articles built this way. A librarian
used a modified (via VBA) version of Word to type the necessary text
(authors, keywords, etc...) and then apply the appropriate styles (there was
an author style, abstract style, etc...) to the text. Once finished, a VBA
macro would use the text and styles information in the document to create an
xml file, validate it and send it to a unix server for processing.
Even non-nerds should be able to write a thesis this way and you only need a
word template and a few macros. All the 'dangerous' widgets and menus were
removed, leaving only the styles combo box and the buttons that called the
macros, so it was librarian-proof. ;-)
You could also use Xemacs and faces instead of styles.
Anyway, designing an easy way to enter info into the system is a different
story, and I would worry to much about it now...
Kenny Tilton
"Thomas F. Burdick" wrote:
>
> Kenny Tilton <kti...@nyc.rr.com> writes:
> I'm not sure I understand what you want to do with this (hypothetical)
> project.
Motivations:
- support Cl-PDF with page layout stuff
- provide a friendlier example of Cells than the intense internals
perspective offered so far
- CliniSys needs a programmatic way to gen PDF... this could be it.
Non-motivation non-motivations:
- match (or even approach) TeX's typesetting quality
> For the problem domain of TeX, I'd look long and hard at TeX itself,
Our typesetting requirements are not stringent, and I am already very
happy with the way we are laying out pages, so this is starting to look
like a straightforward merge with CL-PDF. Touch wood.
I did look at the Gentle Intro to TeX. I was surprised to see it was not
(at least at the time of that writing) strong on pulling in graphics.
Has that changed?
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"You're not being the ball, Danny."
- Ty, Caddy Shack
Thomas F. Burdick
> "Thomas F. Burdick" wrote:
> >
> > Kenny Tilton <kti...@nyc.rr.com> writes:
> > I'm not sure I understand what you want to do with this (hypothetical)
> > project.
>
> Motivations:
>
> - support Cl-PDF with page layout stuff
So you do mean human-typed stuff, right? Or are you thinking
human-typed and program-generated?
> - provide a friendlier example of Cells than the intense internals
> perspective offered so far
No doubt, I was kind of looking forward to the once-promised class
browser.
> - CliniSys needs a programmatic way to gen PDF... this could be it.
Ah-ha! Human-typed {\it and} programmatically generated!
> Non-motivation non-motivations:
>
> - match (or even approach) TeX's typesetting quality
>
>
> > For the problem domain of TeX, I'd look long and hard at TeX itself,
>
> Our typesetting requirements are not stringent, and I am already very
> happy with the way we are laying out pages, so this is starting to look
> like a straightforward merge with CL-PDF. Touch wood.
Okay, a programatic interface to a typesetting engine -- this I can
see. (Crud, all this talk makes me want to implement TeX in CL --
must resist temptation ... overburdened already ... )
> I did look at the Gentle Intro to TeX. I was surprised to see it was not
> (at least at the time of that writing) strong on pulling in graphics.
> Has that changed?
Well, TeX hasn't changed in some time ... but I've never had any
problem with its graphics support. Of course, I'm a big PostScript
fan, so making everything epsi hasn't been a problem. It's also
entirely possible that a "gentle intro" glosses over some of the more
advanced parts of the TeX language. I learned from the TeXbook.
That established ...
> /if/ i was going to do a layout mechanism for pdf, should it be via
> mark-up? actually, i am thinking a combination of macros for high-level
> layout plus markup to handle large blocks of text, mainly font and
> styling stuff in there, forced page breaks...
I'd think a nice way to do it would be to define the document in terms
of a tree of objects, or something like that, for purposes of the
programatic interface, and have a mark-up that maps to that. Combine
that with a macro system, and the mark-up language would become usable
for human beings.
> and if i am going with markup, should i just use html? tex? xml? other?
I'm a big fan of TeX-style mark-up. When written like normal, sane
humans write it, it looks remarkably sexp-like: {\repetition boy oh
boy, I {\it love} me some \TeX}.
Rahul Jain
> On Sun, 10 Mar 2002 23:25:52 GMT, Kenny Tilton <kti...@nyc.rr.com> wrote:
> >/if/ i was going to do a layout mechanism for pdf, should it be via
> Why PDF? I think it would better to output a generic layout
> specification and then write functions that traverse this data-struc
> and 'compile' it to a specific layout format: PDF, windows
> metafiles, rtf, whatever you need. This way you can start with
> cl-pdf (if that's what you currently need) while letting other
> people add the 'compiler' functions they need.
This is exactly the design of DefDoc :)
> >mark-up? actually, i am thinking a combination of macros for
> >high-level layout plus markup to handle large blocks of text,
> >mainly font and styling stuff in there, forced page breaks...
> >and if i am going with markup, should i just use html? tex? xml?
> >other?
> I think this is a good idea, but I wouldn't use html, tex or
> anything like that. This would force you to write a parser when
> there's NO need for it: use Lisp and you get the parser for
> free. :-)
Except that it would be nice to be able to do something like:
~*(section
() (Double-Quote)
~'(If a double-quote character is read in the document, all the
contents until the next unescaped double-quote are read as
plain text characters.))
See http://linux.rice.edu/~rahul/syntax.lmtex for the entire document.
This is where my generic-reader comes in. The readtable it uses has a
function that is called for doing the interning, so as long as the
characters introducing an expression indicates the entire
microsyntactic structure of the body, I'm fine. Note that in my syntax
description, there are different macro-characters for introducing a
flow-element that is given a parameter vs. one that is not.
> Make sure that these 'low-level' format specifications aren't too
> low-level, otherwise you'll get in trouble when creating long docs
> that must have a coherent format.
Yes, this can occur at a higher level than the 'core' language, as is
done in Lisp itself.
> The 'style-sheet' can be specified as a lisp data structure that is
> interpreted by the 'compiling' functions.
I was thinking of a DEFENVIRONMENT macro or some such which would
allow definition of new ENVIRONMENT subclasses in a simplified way.
The core of the 'compiler' would be a g-f, CONVERT-DEFDOC, which takes
two parameters, the document element and the output file object (whose
type describes the exact format desired). Then all the flexibility of
g-f dispatch and the standard method combination can be used to
'compile' to the target format.
> So, the data structure that represents the generic layout will probably be a
> tree and the text would be the leaves. Instead of making the leaves simple
> strings or strings with markup such as "lisp <em>rules</em>", make them
> text-generator objects.
The leaves of the tree are where I'm fretting the most about
representation. I suppose doing what TeX does and having them be
characters/ligatures will work fine.
> The simplest text-generator would just output the given text as is,
> while others could apply a style inconditionally or according to a
> given cosntraint. You could implement this as a class hierarchy or
> as a Cell with different constraints (including the no-constraint
> constraint :-).
> For example: Apply a forced page break if blah, blah, blah...
I was thinking of following TeX's model of 'badness' and
constraint-based minimization of the badness of a document being the
guts of the layout engine, but DefDoc (as evidenced by its former name
of LambdaTeX) is highly TeX-inspired. Some day I'll finish that
writeup of DefDoc's conceptual background indicating how I am trying
to merge Lisp concepts with TeX's model.
I think from what Kenny has said that Cells can't handle this kind of
constraint system (something about it being too complicated, which I
can definitely agree with, especially if you don't need that kind of
system ;).
> I'm now reading Sonya Keene's book and it has some info about
> Concordia (Symbolics text processing app) and how CLOS was used to
> implement it. You might find it inspiring. :-)
Hmm, I forgot it had that info, thanks for reminding me... I'll have
to take a look in the infinite spare time that I have to allocate to
DefDoc... :\
I think this is actually the most comprehensive, complete, and
coherent summary to date of DefDoc's planned design. :)
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain
> I'm not sure I understand what you want to do with this (hypothetical)
> project. Is this something in the vague area of TeX? Ie, for humans
> who want to write their theses and have the macine lay them out? Or
> is it for programs that want to spit out their output in a nicely
> layed-out fashion? Or for on-screen GUI stuff? Or is for a system
> that can handle all three?
Regarding DefDoc, I want all three in the long run, the first two in
the beginning. Since the internal format will be CLOS objects, I'll
get the second for free (since of course all useful applications will
be able to create CLOS objects ;).
> For the problem domain of TeX, I'd look long and hard at TeX itself,
> both on the outside
The most glaringly obvious problem with TeX is the syntax. Look at any
non-trivial macros and look at how they treat code. Being able to say
"in this region, I want to optimize for code" and same for text is, I
think, useful. Also, try to figure out what exactly is a token in TeX
:) (see also below).
> and the inside.
Well, that can be a scarring experience. I've found the code to be
utterly unreadable, partly due to this "literate programming" thing,
which makes it nearly impossible to figure out what the code is
_really_ doing because you're flipping all over the place to find the
code that's in the current function body. I have a feeling that Knuth
needed literate programming because Pascal wasn't expressive enough
for him to be able to split up his functions into smaller, easily
documentable, functions and macros.
That said, one of the side-projects I'm thinking about for DefDoc is a
Lisp code pretty-printing and layout engine (which will re-do
line-breaking and indentation to fit the parameters (constraints) you
specify). A side-project of that is a structured Lisp code editor to
go along with this, complete with anchored, floating comments.
> The problem isn't solved perfectly, by any means, but I've yet to
> see any other piece of software that does it as well -- hell, I've
> yet to see one that does it more than half as well.
Agreed. This is the only reason why I still use LaTeX right now.
> Which is not to say we don't need another TeX implementation,
> especially an extensible (on the inside) one in Lisp.
Hopefully, that's what DefDoc will be if it ever really ends up
existing.
Harald Hanche-Olsen
| Kenny Tilton <kti...@nyc.rr.com> writes:
|
| > I did look at the Gentle Intro to TeX. I was surprised to see it
| > was not (at least at the time of that writing) strong on pulling
| > in graphics. Has that changed?
|
| Well, TeX hasn't changed in some time ... but I've never had any
| problem with its graphics support. Of course, I'm a big PostScript
| fan, so making everything epsi hasn't been a problem.
pdftex is pretty good at graphics inclusion. Quoting from the manual:
pdfTeX supports inclusion of pictures in png, jpeg, tiff and pdf
format. The most common technique the inclusion of eps figures is
replaced by pdf inclusion. eps files can be converted to pdf by
GhostScript, Acrobat Distiller or other PostScript--to--pdf
convertors.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?
Pierre R. Mai
> otay, not saying i am actually going to do this, but I can see how it
> might even benefit the mother company, so....
>
> /if/ i was going to do a layout mechanism for pdf, should it be via
> mark-up? actually, i am thinking a combination of macros for high-level
> layout plus markup to handle large blocks of text, mainly font and
> styling stuff in there, forced page breaks...
>
> and if i am going with markup, should i just use html? tex? xml? other?
I'd want to have:
a) A completely functional layer (like the functional layer underlying
CLOS), that allows construction of layout objects, which can then
be laid out via the layout engine to the target format(s).
b) On top of that, a nice macro-layer for use by CL programs.
This provides a complete solution for program-generated content.
For static content, people can then implement (using a), their own
_non-generalized_, _non-standard_ markup-languages, where the CL
transformation program maps markup (possibly via semantic objects) to
layout objects. People infected by the *ML virus can of course use
the full horror of *ML, DTDs, outsourced validators, etc.
The point is that the existence of a) is critical, all else is
syntactic sugar. And most of the hard work is actually coming up with
a powerful spec for layout objects, the functional API, and writing a
high-quality layout engine.
Regs, Pierre.
--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Dorai Sitaram
>> (Symbolics text processing app) and how CLOS was used to implement it. You
>> might find it inspiring. :-)
>
>Hmm, lost my copy. I really should have one on hand. Thx for the tip.
Is this a new edition of Keene's book? In my edition,
she says that Concordia was written in an
object-oriented language, and suggests that it
could, in principle, be rewritten in CLOS...
--d
Fernando Rodríguez
Oops, you're right: Apparently it was written with "New Flavors" (whatever
that is or was), not CLOS.
Kenny Tilton
"Thomas F. Burdick" wrote:
> No doubt, I was kind of looking forward to the once-promised class
> browser.
As I said in the last release notes, I go where the interest is and the
only interest I heard was in seeing what already had been released
released for other Lisps and other languages. Off I went. And now a
groovy class browser (as much fun as that would be) is off on a siding
until we get a Common GUI. Again, one nice advantage of cellular pdf is
that pdf is already cross-everything.
>
> > - CliniSys needs a programmatic way to gen PDF... this could be it.
>
> Ah-ha! Human-typed {\it and} programmatically generated!
As someone noted, down the road the all-markup-all-the-time crowd can do
that on top of a markup-inside-a-language hack.
> Okay, a programatic interface to a typesetting engine
well, I am not getting into variable spacing of words or ligatures or
anything like that. i still have a day job and that does not need such
hig quality.
> I'd think a nice way to do it would be to define the document in terms
> of a tree of objects, or something like that, for purposes of the
> programatic interface, and have a mark-up that maps to that. Combine
> that with a macro system, and the mark-up language would become usable
> for human beings.
having looked at TeX, a wysiwyg PDF editor seems kinder and gentler.
Rahul Jain
> having looked at TeX, a wysiwyg PDF editor seems kinder and gentler.
Be careful that you're not blaming the concept of document generation
from markup languages for the pain that TeX's syntax and relegation of
programming to a special-case causes.