An initial milestone in the development of DefDoc has been reached: I
have created a DefDoc webpage created using DefDoc itself. See
<http://www.common-lisp.net/project/defdoc/>.
Currently, the only functioning output engine is the HTML one. It can
break a document into multiple HTML pages based on the desired number of
words per page.
Next, I'm looking at implementing one of: PDF output, DVI output,
engine-specific options, or multi-dimensional break searching. Anyone
who would like to contribute is encouraged to do so.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@localhost.localdomain> writes:
> An initial milestone in the development of DefDoc has been reached: I
Are DefDoc and cl-typesetting intended to solve the same kind of
problems? What are their differences?
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Paolo Amoroso <·······@mclink.it> writes:
> Rahul Jain <·····@localhost.localdomain> writes:
>
>> An initial milestone in the development of DefDoc has been reached: I
>
> Are DefDoc and cl-typesetting intended to solve the same kind of
> problems? What are their differences?
DefDoc does more than just typesetting. It starts off providing a way of
doing extensible markup so that the markup can be semantic.
Then that marked-up content can be translated to any format whatsoever.
Currently it only translates to HTML. The breaking engine needs to be
much more flexible, as it's now breaking up the document into
flexibly-sized pieces.
From what I can tell of cl-typesetting, it's more akin to a graphics
program with good text handling. I haven't looked too deeply into it,
tho, as I started DefDoc before Marc started talking about
cl-typesetting. I'm strongly considering using cl-pdf in the pdf output
engine, however.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
"Rahul Jain" <·····@nyct.net> writes:
> Paolo Amoroso <·······@mclink.it> writes:
>
> > Are DefDoc and cl-typesetting intended to solve the same kind of
> > problems? What are their differences?
>
> DefDoc does more than just typesetting. It starts off providing a way of
> doing extensible markup so that the markup can be semantic.
>
> Then that marked-up content can be translated to any format whatsoever.
> Currently it only translates to HTML. The breaking engine needs to be
> much more flexible, as it's now breaking up the document into
> flexibly-sized pieces.
>
> From what I can tell of cl-typesetting, it's more akin to a graphics
> program with good text handling. I haven't looked too deeply into it,
> tho, as I started DefDoc before Marc started talking about
> cl-typesetting. I'm strongly considering using cl-pdf in the pdf output
> engine, however.
From what I've seen of DefDoc the projects are indeed intended to solve the
same problem: Providing an alternative to TeX and TeX like systems.
There is also another project which wants to redo TeX in Common Lisp.
Looks like the topic is fashionable ;-)
The ways of doing it are different though.
As I understand it, Rahul is starting by the document layer.
I use a bottom up approach:
1-physical layer : cl-pdf
2-layout layer : cl-typesetting
(For HTML the physical and layout layers are already handled by the HTML
generation macros (lml2, cl-who, htout, html-gen, etc.))
3-document layer : Not yet done.
4-syntax layers : Hmm, I'm still waiting for all those cool user friendly
syntaxes...
For 3 and 4, I have an sexpr representation which I adopted after some
discussion here. But I always made it clear that I wanted to be able to input
lots of different syntaxes (TeX/LaTeX, sexpr, Lisp user friendly syntaxes,
etc.)
A cl-typesetting example:
http://www.fractalconcept.com/ex.pdf
cl-pdf:
http://www.fractalconcept.com/asp/html/cl-pdf
cl-typesetting:
http://www.fractalconcept.com/asp/html/cl-typesetting
Marc
"Marc Battyani" <·············@fractalconcept.com> writes:
> From what I've seen of DefDoc the projects are indeed intended to solve the
> same problem: Providing an alternative to TeX and TeX like systems.
Though it's not really completely obvious that "replace TeX" is a
single problem anyway. "TeX like systems" spans a wide range of uses,
from the TeXbook-wielding obsessive who agonizes about italic
correction, edits the actual words in the document to avoid overfull
boxes, and probably knows how to use metafont, to the LaTeX user who
espouses the "separation of content and presentation" religion, uses
someone else's canned format and probably doesn't even need a dvi
previewer except perhaps to check that any particularly complicated
maths came out right.
-dan
--
"please make sure that the person is your friend before you confirm"
Sorry for the delay in replying. I've been busy and haven't had a chance
to formulate a complete-ish reply till now.
"Marc Battyani" <·············@fractalconcept.com> writes:
> The ways of doing it are different though.
>
> As I understand it, Rahul is starting by the document layer.
That is quite true. Although, in doing that, I have used TeX's
line-breaking algorithm. :)
> I use a bottom up approach:
> 1-physical layer : cl-pdf
> 2-layout layer : cl-typesetting
One thing I wanted to have in DefDoc is the ability to tweak the
breaking algorithm for any part of the document, as well as have the
breakpoint search be multi-dimensional instead of one-dimensional as
TeX's is. Could this be accommodated by cl-typesetting? If not, would
you be interested in modifying cl-typesetting to accomodate it?
> (For HTML the physical and layout layers are already handled by the HTML
> generation macros (lml2, cl-who, htout, html-gen, etc.))
I created my own because I don't need anything fancy, just something
that gets the job done in a way that makes sense for DefDoc's
html-engine.
> 3-document layer : Not yet done.
As you said above, this is where I am right now.
> 4-syntax layers : Hmm, I'm still waiting for all those cool user friendly
> syntaxes...
I've been working on this part, and it'll need a custom lispy reader. In
fact, so will DefEditor's lisp mode. In fact, I'm thinking of
implementing the DefEditor DefDoc mode before implementing the nice
textual frontend syntax for DefDoc. This is so that I can format the
document for the user however I like without the need to have to play
around with parsing a not-yet-defined format. The on-screen view from
DefEditor is intended to closely resemble the textual DefDoc form, so it
will be easy to use DefEditor as a prototyping environment for that.
> For 3 and 4, I have an sexpr representation which I adopted after some
> discussion here. But I always made it clear that I wanted to be able to input
> lots of different syntaxes (TeX/LaTeX, sexpr, Lisp user friendly syntaxes,
^^^^^^^^^^^^^^^^^^^^^^^^^^^
e.g., DefDoc :)
> etc.)
BTW, I think I missed the sexpr-representation-of-documents discussion
you alluded to. If you can dig up a groups.google.com link to this
thread, I'd be much obliged. (As though I'm not already for cl-pdf. ;)
Daniel Barlow <···@telent.net> writes:
> "Marc Battyani" <·············@fractalconcept.com> writes:
>
>> From what I've seen of DefDoc the projects are indeed intended to solve the
>> same problem: Providing an alternative to TeX and TeX like systems.
>
> Though it's not really completely obvious that "replace TeX" is a
> single problem anyway. "TeX like systems" spans a wide range of uses,
> from the TeXbook-wielding obsessive who agonizes about italic
> correction, edits the actual words in the document to avoid overfull
> boxes, and probably knows how to use metafont, to the LaTeX user who
> espouses the "separation of content and presentation" religion, uses
> someone else's canned format and probably doesn't even need a dvi
> previewer except perhaps to check that any particularly complicated
> maths came out right.
That is a good point. I'm aiming to create a layered system that is
_inspired_ by both TeX and LaTeX. Since I'm targeting multiple output
formats, some of which are not typeset, pure typesetting (which
encourages editing of content to fix layout -- which, BTW, could
probably be avoided by giving spaces a small shrinkability) is not my
goal. I'm of the latter persuation, where content is what matters and
presentation is a matter of the characteristics of the target format for
this viewing.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
"Rahul Jain" <·····@nyct.net> writes:
>
> Sorry for the delay in replying. I've been busy and haven't had a chance
> to formulate a complete-ish reply till now.
I know what it is. Time is a very limited resource.
> "Marc Battyani" <·············@fractalconcept.com> writes:
>
> > The ways of doing it are different though.
> >
> > As I understand it, Rahul is starting by the document layer.
>
> That is quite true. Although, in doing that, I have used TeX's
> line-breaking algorithm. :)
>
> > I use a bottom up approach:
> > 1-physical layer : cl-pdf
> > 2-layout layer : cl-typesetting
>
> One thing I wanted to have in DefDoc is the ability to tweak the
> breaking algorithm for any part of the document, as well as have the
> breakpoint search be multi-dimensional instead of one-dimensional as
> TeX's is. Could this be accommodated by cl-typesetting? If not, would
> you be interested in modifying cl-typesetting to accomodate it?
Sure, I even already made a call for participation here on this subject:
http://groups.google.com/groups?selm=blvd5r%24tik%40library2.airnews.net
I didn't put the TeX algorithm so far because I have a more powerful box
engine that gives more possibilities than what is available for TeX. So I
think that it is interesting to look at the TeX algorithm for the base ideas
but to make something more up-to-date. For instance, in my example at
http://www.fractalconcept.com/ex.pdf you can see that there is some "white
space rivers" detection and highlighting. (The red lines in the upper right
text block) I also have a small amount of compression and expansion for the
characters widths and intra-characters spacing, etc.
[...]
> > 4-syntax layers : Hmm, I'm still waiting for all those cool user
friendly
> > syntaxes...
>
> I've been working on this part, and it'll need a custom lispy reader. In
> fact, so will DefEditor's lisp mode. In fact, I'm thinking of
> implementing the DefEditor DefDoc mode before implementing the nice
> textual frontend syntax for DefDoc. This is so that I can format the
> document for the user however I like without the need to have to play
> around with parsing a not-yet-defined format. The on-screen view from
> DefEditor is intended to closely resemble the textual DefDoc form, so it
> will be easy to use DefEditor as a prototyping environment for that.
I also looked at this as it's easy to directly draw to the screen from
cl-typesetting. You can also easily find where you are in the document from
the x,y coordinates of a cursor or a mouse click. So a wysiwyg editor is easy
to implement. But I did not continue in that direction for lack of time and
lack of a standard cross platform GUI. I still think it's interesting but
it's not a priority for me.
> > For 3 and 4, I have an sexpr representation which I adopted after some
> > discussion here. But I always made it clear that I wanted to be able to
input
> > lots of different syntaxes (TeX/LaTeX, sexpr, Lisp user friendly
syntaxes,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> e.g., DefDoc :)
Sure! ;-)
The syntax layer is a very open subject. As you can see in the Usenet threads
below, one syntax can't fit all. The DefDoc syntax looks like the
cl-typesetting lisp-layer syntax though it has higher level items (like
section) while cl-typesetting has more low-level ones.
> BTW, I think I missed the sexpr-representation-of-documents discussion
> you alluded to. If you can dig up a groups.google.com link to this
> thread, I'd be much obliged. (As though I'm not already for cl-pdf. ;)
The first thread is here:
http://groups.google.com/groups?selm=bkkvpe%244ar%40library2.airnews.net
Another thread about the syntax is here:
http://groups.google.com/groups?selm=blbe87%24gei%40library2.airnews.net
Followed here:
http://groups.google.com/groups?selm=blc0dn%24t4i%40library2.airnews.net
With a conclusion here:
http://groups.google.com/groups?selm=blcdtj%24f0r%40library2.airnews.net
Marc
"Marc Battyani" <·············@fractalconcept.com> writes:
> "Rahul Jain" <·····@nyct.net> writes:
>>
>> Sorry for the delay in replying. I've been busy and haven't had a chance
>> to formulate a complete-ish reply till now.
>
> I know what it is. Time is a very limited resource.
Indeed, and this very reply is a reaffirmation of that statement!
>> One thing I wanted to have in DefDoc is the ability to tweak the
>> breaking algorithm for any part of the document, as well as have the
>> breakpoint search be multi-dimensional instead of one-dimensional as
>> TeX's is. Could this be accommodated by cl-typesetting? If not, would
>> you be interested in modifying cl-typesetting to accomodate it?
>
> Sure, I even already made a call for participation here on this subject:
> http://groups.google.com/groups?selm=blvd5r%24tik%40library2.airnews.net
Ok, thanks. I must have been AWOL when that happened, or just not paying
attention. :)
> I didn't put the TeX algorithm so far because I have a more powerful box
> engine that gives more possibilities than what is available for TeX. So I
> think that it is interesting to look at the TeX algorithm for the base ideas
> but to make something more up-to-date. For instance, in my example at
> http://www.fractalconcept.com/ex.pdf you can see that there is some "white
> space rivers" detection and highlighting. (The red lines in the upper right
> text block) I also have a small amount of compression and expansion for the
> characters widths and intra-characters spacing, etc.
Ok, it looks like you're doing some more complex stuff than TeX does,
_but_ I think the basics of the TeX breaking algorithm are good.
Basically, it's an iteratively-widening least-path-cost search.
Penalties are the length of the path and based on the cube of how much
relative compression and expansion is occurring plus various penalties
for specific situations, including widows and orphans. The most
important extension to TeX's breaking algorithm that I'd like is that
TeX breaks text into lines and then lines into pages. If it's possible
to avoid an orphanned line by just compressing the spacing a bit on one
line and bringing some words up from the next line, it will not do that.
> I also looked at this as it's easy to directly draw to the screen from
> cl-typesetting. You can also easily find where you are in the document from
> the x,y coordinates of a cursor or a mouse click. So a wysiwyg editor is easy
> to implement. But I did not continue in that direction for lack of time and
> lack of a standard cross platform GUI. I still think it's interesting but
> it's not a priority for me.
I've decided to use CLIM, since McCLIM is making great progress. I'm not
interested in a WYSIWYG editor, as that defeats the purpose of trying to
replace TeX and goes against the entire way that DefDoc is supposed to
work. Aesthetic constraints are applied at the level of the output
engine, not at the level of the content. The content can be marked up
with aesthetic hints for all or some output engines. Furthermore, I'm
targetting many fundamentally different output formats. HTML will be
wrapped and sized to the user's preferences (possibly with input from
the style sheet, which could be generated from the aesthetic desires
expressed in the document).
> The syntax layer is a very open subject. As you can see in the Usenet threads
> below, one syntax can't fit all. The DefDoc syntax looks like the
> cl-typesetting lisp-layer syntax though it has higher level items (like
> section) while cl-typesetting has more low-level ones.
>
>> BTW, I think I missed the sexpr-representation-of-documents discussion
>> you alluded to. If you can dig up a groups.google.com link to this
>> thread, I'd be much obliged. (As though I'm not already for cl-pdf. ;)
OK, this is all pretty close to what I've thought about, but I've
managed to make it so that parens for code, delimiters, and text only
need to be escaped if the text is interleaved with any of the others.
(Or an entire text string can be multiply-escaped.)
-----
Now, getting down to business, I think I might want to change my
basic-elements class structure if it won't match well to
cl-typesetting's concepts of basic document elements.
I've defined classes for elements that connect horizontally and
vertically and elements that contain elements that connect. There are
then mixins to determine whether breaking occurs by wrapping or
overflowing into other containers (e.g., for newspapers and magazines)
and for (optional) floating and flowing into the parent container.
Actually I'm not sure that flowing is really required, as a wrapping
container within another wrapping container of the same orientation
should always flow into the parent container, no? Currently, most of
this information is ignored.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
"Rahul Jain" <·····@nyct.net> writes:
> Paolo Amoroso <·······@mclink.it> writes:
>
> > Are DefDoc and cl-typesetting intended to solve the same kind of
> > problems? What are their differences?
>
> DefDoc does more than just typesetting. It starts off providing a way of
> doing extensible markup so that the markup can be semantic.
>
> Then that marked-up content can be translated to any format whatsoever.
> Currently it only translates to HTML. The breaking engine needs to be
> much more flexible, as it's now breaking up the document into
> flexibly-sized pieces.
>
> From what I can tell of cl-typesetting, it's more akin to a graphics
> program with good text handling. I haven't looked too deeply into it,
> tho, as I started DefDoc before Marc started talking about
> cl-typesetting. I'm strongly considering using cl-pdf in the pdf output
> engine, however.
From what I've seen of DefDoc the projects are indeed intended to solve the
same problem: Providing an alternative to TeX and TeX like systems.
There is also another project which wants to redo TeX in Common Lisp.
Looks like the topic is fashionable ;-)
The ways of doing it are different though.
As I understand it, Rahul is starting by the document layer.
I use a bottom up approach:
1-physical layer : cl-pdf
2-layout layer : cl-typesetting
(For HTML the physical and layout layers are already handled by the HTML
generation macros (lml2, cl-who, htout, html-gen, etc.))
3-document layer : Not yet done.
4-syntax layers : Hmm, I'm still waiting for all those cool user friendly
syntaxes...
For 3 and 4, I have an sexpr representation which I adopted after some
discussion here. But I always made it clear that I wanted to be able to input
lots of different syntaxes (TeX/LaTeX, sexpr, Lisp user friendly syntaxes,
etc.)
A cl-typesetting example:
http://www.fractalconcept.com/ex.pdf
cl-pdf:
http://www.fractalconcept.com/asp/html/cl-pdf
cl-typesetting:
http://www.fractalconcept.com/asp/html/cl-typesetting
Marc
Rahul Jain <·····@localhost.localdomain> writes:
> An initial milestone in the development of DefDoc has been reached:
> I have created a DefDoc webpage created using DefDoc itself. See
> <http://www.common-lisp.net/project/defdoc/>.
On the web page you write:
> I have written up a document that is an overview of the goals and
> rationale behind DefDoc. It is available as LaTeX, PDF, and
> Postscript.
Would it also be possible to have HTML as well?
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
David Magda <··················@ee.ryerson.ca> writes:
>> I have written up a document that is an overview of the goals and
>> rationale behind DefDoc. It is available as LaTeX, PDF, and
>> Postscript.
>
> Would it also be possible to have HTML as well?
Yeah, I'll do that now.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist