Menu
▾
▴
xmlroff-list — xmlroff XSL formatter discussion list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(8) |
Mar
(38) |
Apr
(13) |
May
(17) |
Jun
(9) |
Jul
(31) |
Aug
(5) |
Sep
|
Oct
(9) |
Nov
(8) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(8) |
Feb
(2) |
Mar
(10) |
Apr
(1) |
May
(6) |
Jun
(4) |
Jul
|
Aug
(32) |
Sep
(20) |
Oct
(26) |
Nov
(2) |
Dec
(1) |
| 2005 |
Jan
(6) |
Feb
(9) |
Mar
(69) |
Apr
(13) |
May
(7) |
Jun
(21) |
Jul
(9) |
Aug
(21) |
Sep
(28) |
Oct
|
Nov
(15) |
Dec
(1) |
| 2006 |
Jan
(32) |
Feb
(47) |
Mar
(44) |
Apr
(10) |
May
(5) |
Jun
(7) |
Jul
(21) |
Aug
(5) |
Sep
(1) |
Oct
|
Nov
|
Dec
(4) |
| 2007 |
Jan
|
Feb
(12) |
Mar
(7) |
Apr
(10) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Tony G. <Ton...@Su...> - 2003-03-20 17:49:02
|
Tony Graham wrote at 19 Mar 2003 17:12:45 +0000: > This list is being (unsuccessfully) spammed by 'Ifujian', and so are > both my work and private SourceForge personas. Since xmlroff is the > only place where all three overlap, I'm wondering if anybody else is > being similarly spammed. Since no-one else has said they are being spammed, I guess I must be privileged. While I'm glad that no-one else is being spammed, that's one privilege I can do without. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
|
From: Noah L. <nl...@co...> - 2003-03-19 17:22:52
|
On Wed, Mar 19, 2003 at 17:04:28 +0000, Tony Graham wrote: > > Please file an enhancement request on the SourceForge site. Ok: http://sourceforge.net/tracker/index.php?func=detail&aid=706397&group_id=73148&atid=536900 (I accidentally filed it anonymously, sorry about that.) > > 'none' and 'all' would be pretty simple, 'default' to not embed the > famous 14 or so will require a bit of string matching, once I find the > right strings to use. I found the following font names at http://www.foolabs.com/xpdf/problems.html Times-Roman Times-Italic Times-Bold Times-BoldItalic Helvetica Helvetica-Oblique Helvetica-Bold Helvetica-BoldOblique Courier Courier-Oblique Courier-Bold Courier-BoldOblique Symbol ZapfDingbats Not sure if this helps. I imagine the matching should be case-insensitive. Noah |
|
From: Tony G. <Ton...@Su...> - 2003-03-19 17:13:13
|
Are people receiving spam from 'Ifujian' through their email address used by SourceForge and/or the address used by the xmlroff-list mailing list? This list is being (unsuccessfully) spammed by 'Ifujian', and so are both my work and private SourceForge personas. Since xmlroff is the only place where all three overlap, I'm wondering if anybody else is being similarly spammed. It is sufficient to reply to me privately. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
|
From: Tony G. <Ton...@Su...> - 2003-03-19 17:04:51
|
Noah Levitt wrote at 18 Mar 2003 11:04:37 -0500:
> Hmm, the problems you have in mind are much more complicated
> than what I was thinking of. :-)
>
> I propose a command-line option:
>
> --embed-fonts={none,default,all}
>
> If --embed-fonts=default, which would the default if the
> command-line option is not specified, then all fonts are
> embedded except the 14 standard Adobe fonts.
>
> I think this works at least as a provisional solution.
Please file an enhancement request on the SourceForge site.
'none' and 'all' would be pretty simple, 'default' to not embed the
famous 14 or so will require a bit of string matching, once I find the
right strings to use.
Regards,
Tony Graham
------------------------------------------------------------------------
XML Technology Center - Dublin
Sun Microsystems Ireland Ltd Phone: +353 1 8199708
Hamilton House, East Point Business Park, Dublin 3 x(70)19708
|
|
From: Noah L. <nl...@co...> - 2003-03-18 16:05:39
|
Hmm, the problems you have in mind are much more complicated
than what I was thinking of. :-)
I propose a command-line option:
--embed-fonts={none,default,all}
If --embed-fonts=default, which would the default if the
command-line option is not specified, then all fonts are
embedded except the 14 standard Adobe fonts.
I think this works at least as a provisional solution.
Noah
On Tue, Mar 18, 2003 at 11:29:15 +0000, Tony Graham wrote:
>
> Part of the problem is that I'm unsure of exactly what is required.
>
|
|
From: Noah L. <nl...@co...> - 2003-03-18 15:50:34
|
On Tue, Mar 18, 2003 at 11:07:22 +0000, Tony Graham wrote: > Noah Levitt wrote at 16 Mar 2003 12:29:34 -0500: > > A useful project would be a collection of standardized xml > > doctypes and corresponding xsl stylesheets for common types > > of documents, such as letters, articles, books, etc. Does > > such a thing exist? > > I'd suggest using DocBook and Norm Walsh's stylesheets for articles > and books. See http://sourceforge.net/projects/docbook/. > > Various people have published stylesheets for XHTML as well. > > There's undoubtedly also stylesheets for formatting TEI (Text Encoding > Initiative) documents. Thanks for the pointers. Nothing for letters though, I guess, which happen to be what I was writing. :-) > > My question is, are you suggesting this as useful for xmlroff or for > XSL in general? > For XSL in general, certainly. Noah |
|
From: Tony G. <Ton...@Su...> - 2003-03-18 11:29:40
|
Noah Levitt wrote at 16 Mar 2003 12:27:24 -0500: > On Thu, Mar 13, 2003 at 17:51:54 +0000, Tony Graham wrote: > > > > I could add an embed/no-embed flag to the PDF backend of PangoPDF > > fairly easily, but per-font embedding control would require an > > enhancement to fontconfig. > > > > Could you explain what the enhancement to fontconfig would > be? I'd like to file a feature request at > http://fontconfig.org/bugzilla/ because I think it's an > important feature for xmlroff to have. Part of the problem is that I'm unsure of exactly what is required. Ideally fontconfig would be able to provide an embed/no-embed flag as part of the information about a font, just like you can get the font's filename from fontconfig. The embed/no-embed information would presumably come from the fonts.conf file, but that potentially means putting a lot of specific font names in fonts.conf whereas the fonts.conf file is currently pretty generic. It is possible to imagine a more localized embed/no-embed control file in each directory containing fonts, but that's a big stretch for the current fontconfig. The other side of the problem is supporting users who have varying needs for embedding fonts. If you want to embed fonts some of the time but not all of the time or you want to sometimes embed every font despite what the improved fontconfig tells you, that would be pretty easy to handle with a three-state flag to PangoPDF. But what if you want to embed different subsets of fonts depending on where you expect the output PDF to be used, e.g., embed none for use on your machine, embed more for use within your company, and embed all but the standard 14 Adobe fonts for use outside your company? That gets into having embed/no-embed controls outside of fontconfig or having embedding profiles in fontconfig, both of which would be messy. > What would be required for xmlroff to support embedding only > the subsets of the fonts that are actually used in the > document? It would require PDFlib to support it, or changing the PDF generation library used by PangoPDF. What I really want is a library that will embed subsets of CJK fonts. > By the way, thanks for xmlroff and pangopdf. I hope you > succeed in getting pangopdf merged into pango. Thanks. PangoPDF probably has to prove its worth (and use a less encumbered PDF library) before it can be accepted into Pango itself. In the short term, I'd be happy if I didn't have to invent so many -private.h files just to be able to subclass some Pango objects. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
|
From: Tony G. <Ton...@Su...> - 2003-03-18 11:07:44
|
Noah Levitt wrote at 16 Mar 2003 12:29:34 -0500: > A useful project would be a collection of standardized xml > doctypes and corresponding xsl stylesheets for common types > of documents, such as letters, articles, books, etc. Does > such a thing exist? I'd suggest using DocBook and Norm Walsh's stylesheets for articles and books. See http://sourceforge.net/projects/docbook/. Various people have published stylesheets for XHTML as well. There's undoubtedly also stylesheets for formatting TEI (Text Encoding Initiative) documents. My question is, are you suggesting this as useful for xmlroff or for XSL in general? Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
|
From: Noah L. <nl...@co...> - 2003-03-16 17:30:36
|
A useful project would be a collection of standardized xml doctypes and corresponding xsl stylesheets for common types of documents, such as letters, articles, books, etc. Does such a thing exist? Noah |
|
From: Noah L. <nl...@co...> - 2003-03-16 17:28:28
|
On Thu, Mar 13, 2003 at 17:51:54 +0000, Tony Graham wrote: > > I could add an embed/no-embed flag to the PDF backend of PangoPDF > fairly easily, but per-font embedding control would require an > enhancement to fontconfig. > Could you explain what the enhancement to fontconfig would be? I'd like to file a feature request at http://fontconfig.org/bugzilla/ because I think it's an important feature for xmlroff to have. What would be required for xmlroff to support embedding only the subsets of the fonts that are actually used in the document? By the way, thanks for xmlroff and pangopdf. I hope you succeed in getting pangopdf merged into pango. Noah |
|
From: Tony G. <Ton...@Su...> - 2003-03-13 17:52:23
|
Noah Levitt wrote at 12 Mar 2003 15:32:42 -0500: > 1. Does xmlroff/pangopdf do justification, using text-align? > I'm attaching a .fo that doesn't justify for me. No. There is a guy on the gtk...@gn... list who has said that he's working on justifying lines in Pango, though. > 2. How do I avoid embedding fonts in my pdf? xmlroff embeds fonts in the PDF as part of a desire to generate PDF/X-compatible PDF. Right now, change the last argument of the PDF_findfont() calls in pangopdflib.c to 0 then recompile PangoPDF. Controlling embedding is an interesting issue, since sometimes you can specify a generic font-family in your FO (e.g., font-family="sans"), so the FO file doesn't always say what fonts are used. The problem is compounded for xmlroff because xmlroff uses Pango which uses fontconfig, and fontconfig doesn't have an 'embed' flag of any kind (hardly surprising given that it's descended from xft). In the general case, you might want to embed only some of the fonts, e.g. the exotic fonts that are unlikely be on someone else's system. I could add an embed/no-embed flag to the PDF backend of PangoPDF fairly easily, but per-font embedding control would require an enhancement to fontconfig. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
|
From: Noah L. <nl...@co...> - 2003-03-12 20:33:48
|
1. Does xmlroff/pangopdf do justification, using text-align? I'm attaching a .fo that doesn't justify for me. 2. How do I avoid embedding fonts in my pdf? Noah |
|
From: Tony G. <Ton...@Su...> - 2003-03-11 13:24:27
|
Dave Malcolm wrote at 9 Mar 2003 13:29:23 +0000: > On Saturday 08 March 2003 20:43, Tony Graham wrote: > > > Even without doing this, the browser should be a fairly simple job using > > > GnomeCanvas. > > > > I had thought that a tree required GtkTree or similar, not a canvas > > widget. What am I missing? > > I was thinking of using the canvas to render rectangular areas that can be > clicked and dragged etc; nice for visual inspection of the results. Mind That would be simple to do (well, comparatively simple) if Pango's FT2 (or xft) backend could take the same PangoLayout as created by the PDFlib backend. Right now, I believe that the FT2 and xft backends are too tied to 72dpi resolution. > you, a tree would be useful as well, for systematic "structural" browsing. > (You probably want GtkTreeView for that; it's much better than the old GTK > 1.* widgets) Yes. I installed GTK+ 2.2.0, and I've looked at the sample code in gtk-demo. > > My blue-sky musing frequently concerns incremental updates: pushing a > > small change, e.g. one changed word, in the source XML through the > > XSLT transformation and through the XSL formatter without either > > transforming the whole document again or reformatting the whole > > document again. > > I wasn't aware this was possible... and if you manage to do it I'll be very > interested in finding out how :-) I've (briefly) looked for "incremental" > XSLT engines but couldn't find any. I haven't found any incremental XSLT engines either, but we are speaking blue-sky, aren't we? The first part of the story, alerting the XSLT engine to a change in the source XML, could be done using something like DOM events [1]. The second part, going the incremental transformation, is left as an exercise for the reader. The third part, alerting the formatter, could also be based on DOM events. The fourth part, changing the formatted output, is not dissimilar from what wil eventually have to be implemented for handling page-number-citation and retrieve-marker and for handling the area-tree adjustment phase. So it's simple, really. > > Also, speaking as list administrator now, please only quote the parts > > of the previous message to which you are directly replying or only > > quote enough to establish the context. Including entire copies of > > previous messages reduces the signal-to-noise ratio in SourceForge's > > one-thread-per-page mailing list archives. > > Oops... sorry. That's okay. Some people's normal habits don't play well with SourceForge's archive style, but you can't know that until you look in the archives (or someone tells you). Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 [1] http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-EventTypes-complete |
|
From: Tony G. <Ton...@Su...> - 2003-03-11 12:43:50
|
james anderson wrote at 7 Mar 2003 14:08:28 +0100: > is there a dtd/schema for the xml source document for your transformation to pdf? is it somewhere in the release? There is a DTD for Javadoc XML, but AFAIK the whole Javadoc XML work is experimental, and the DTD is not mine to make public. The Javadoc XML example handles the Javadoc XML as well-formed XML only. The example stylesheet does not attempt to handle every possible combination of the elements and attributes in the example XML file. It certainly doesn't attempt to handle every possible element and attribute in a DTD that models all of Javadoc. In fact, as noted in the README and on the Javadoc XML example web page, the example presupposes some munging from real Javadoc XML to an intermediate form that includes class names, etc., from what would have originally been multiple Javadoc XML files. As such, it's unlikely that you'd want a DTD for the XML used as input to the example stylesheet. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
|
From: Dave M. <da...@da...> - 2003-03-11 12:33:41
|
On Saturday 08 March 2003 20:43, Tony Graham wrote: > > Even without doing this, the browser should be a fairly simple job using > > GnomeCanvas. > > I had thought that a tree required GtkTree or similar, not a canvas > widget. What am I missing? I was thinking of using the canvas to render rectangular areas that can be clicked and dragged etc; nice for visual inspection of the results. Mind you, a tree would be useful as well, for systematic "structural" browsing. (You probably want GtkTreeView for that; it's much better than the old GTK 1.* widgets) > My blue-sky musing frequently concerns incremental updates: pushing a > small change, e.g. one changed word, in the source XML through the > XSLT transformation and through the XSL formatter without either > transforming the whole document again or reformatting the whole > document again. I wasn't aware this was possible... and if you manage to do it I'll be very interested in finding out how :-) I've (briefly) looked for "incremental" XSLT engines but couldn't find any. > > Also, speaking as list administrator now, please only quote the parts > of the previous message to which you are directly replying or only > quote enough to establish the context. Including entire copies of > previous messages reduces the signal-to-noise ratio in SourceForge's > one-thread-per-page mailing list archives. Oops... sorry. |
|
From: james a. <jam...@se...> - 2003-03-11 00:05:36
|
hello; is there a dtd/schema for the xml source document for your transformation to pdf? is it somewhere in the release? thanks. ... |
|
From: james a. <jam...@se...> - 2003-03-11 00:04:02
|
hello; is there a dtd/schema for the xml source document for your transformation to pdf? is it somewhere in the release? thanks. ... |
|
From: Tony G. <Ton...@Su...> - 2003-03-08 20:43:48
|
Dave Malcolm wrote at 8 Mar 2003 16:44:48 +0000: > Please forgive my ignorance, but is there a standard DTD for the area tree > stage? That way you can just serialise the area tree as XML, and the There isn't a standard DTD for the area tree. It isn't standardised by the XSL 1.0 Recommendation. It was one of the first things that came up for discussion when the EXSL-FO list started up, but the discussion died after Ken Holman said that he knew of a formatter that didn't produce an area tree. Serialising either tree as XML would just require a simple variation on the 'xmlroff -d2' or 'xmlroff -d4' output, which uses fo_object_debug_dump(). > graphical view can be an entirely separate app. Might well make debugging > easier. Half the point of the browser idea is to prototype the loadable module approach. Writing it out as XML and using a separate app doesn't help that part of the scenario. Note also that the proposal is to be able to show both FO tree and area tree views at once. > Even without doing this, the browser should be a fairly simple job using > GnomeCanvas. I had thought that a tree required GtkTree or similar, not a canvas widget. What am I missing? > Unfortunately I have a million-and-one other things to do at > the moment... :-( Don't we all, and many of mine already have to do with xmlroff. > <blue-sky-musing> > I'm hoping to add custom previews to my app Conglomerate > (www.conglomerate.org) that automatically update as you edit the XML DocBook > source; one possibility would be a FO area tree view showing the "live" > results of XSL transformations... > </blue-sky-musing> My blue-sky musing frequently concerns incremental updates: pushing a small change, e.g. one changed word, in the source XML through the XSLT transformation and through the XSL formatter without either transforming the whole document again or reformatting the whole document again. Also, speaking as list administrator now, please only quote the parts of the previous message to which you are directly replying or only quote enough to establish the context. Including entire copies of previous messages reduces the signal-to-noise ratio in SourceForge's one-thread-per-page mailing list archives. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
|
From: Dave M. <da...@da...> - 2003-03-08 15:42:55
|
Please forgive my ignorance, but is there a standard DTD for the area tree stage? That way you can just serialise the area tree as XML, and the graphical view can be an entirely separate app. Might well make debugging easier. Even without doing this, the browser should be a fairly simple job using GnomeCanvas. Unfortunately I have a million-and-one other things to do at the moment... :-( <blue-sky-musing> I'm hoping to add custom previews to my app Conglomerate (www.conglomerate.org) that automatically update as you edit the XML DocBook source; one possibility would be a FO area tree view showing the "live" results of XSL transformations... </blue-sky-musing> Dave Malcolm On Thursday 06 March 2003 13:00, Tony Graham wrote: > Posted here and on the xmlroff Wiki to see which one generates the > most responses. > > Regards, > > > Tony Graham > ------------------------------------------------------------------------ > XML Technology Center - Dublin > Sun Microsystems Ireland Ltd Phone: +353 1 8199708 > Hamilton House, East Point Business Park, Dublin 3 x(70)19708 > > ------------------------------------------------------------ > FO and Area Tree Browser > > The xmlroff design calls for an 'Area Tree Adjust' stage after the > initial formatting is done and before the area tree is written out as > PDF, etc. > > The intent is to call loadable modules to do the work. > > An idea for an initial loadable module that doesn't actually adjust > the area tree is to make a graphical browser that shows the FO and > area trees. > > The browser would be: > > *proof-of-concept for the loadable module technique > *useful visualisation tool for XSL > *useful debugging aid > *basis for eventual manual area-tree-tweaker > > The current idea is a multi-pane or multi-window browser showing: > > *FO tree > *Properties of currently selected FO > *Areas generated by currently selected FO > *Area tree with currently selected area highlighted > *Properties of currently selected area > > In principle this could be extended to include panes or windows for: > > *Formatted output with currently selected area highlighted > *Input XML document(s) with element or attribute that generated > currently selected FO highlighted > > (All of which would really fuel the market for multi-head displays.) > > GNOME or GTK+ would be the obvious choice for windowing toolkit, but > it could instead be done in Tk or any of a number of other > technologies. > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger > for complex code. Debugging C/C++ programs can leave you feeling lost and > disoriented. TotalView can help you find your way. Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > xmlroff-list mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlroff-list |
|
From: Tony G. <Ton...@Su...> - 2003-03-07 16:51:13
|
Charles Bozeman wrote at 6 Mar 2003 19:53:44 -0600:
> I think this is an excellent idea especially your idea of seeing the
> formated output in one pane and the FO and properties in another. I am
The formatted output is an eventual option. I'm proposing to start
with just the trees, which will be simpler to implement.
> discovering that it is difficult to determine if a fo has been rendered
> correctly; even a small fo has a lot of complexities. I also like the
> idea of having loadable modules to work at different stages of
> formatting. I can image not only being able to choose different output
> formats but also having a choice different algorithms during the
> adjustment phase.
xmlroff currently doesn't do loadable modules. It doesn't do loadable
modules for the output format simply because there's currently only
one supported output format.
My intention has always been to have loadable modules for the
adjustment phase to allow, as you say, a choice of different
algorithms during the adjustment phase.
> I've never worked on a GUI application before and I image this one is
> not too easy, but I'll bet it will pay off in the long run.
GTK+ (and GNOME) has a tree widget. It seems to me that it would be
straightforward to walk the FO tree or the area tree and make a
corresponding GTK+ tree. Having made the GTK+ tree from the FO or
area tree, it should be easy to get from a selected widget in the GTK+
tree to the corresponding FoFo or FoArea, and you can get from an FoFo
to its areas or from an FoArea to its FoFo easily enough. After that,
it's "just" a matter of updating the appropriate windows and selecting
the appropriate widgets.
Presumably the GUI builders such as the Glade application will make
the GUI side easy to implement.
Regards,
Tony Graham
------------------------------------------------------------------------
XML Technology Center - Dublin
Sun Microsystems Ireland Ltd Phone: +353 1 8199708
Hamilton House, East Point Business Park, Dublin 3 x(70)19708
P.S. Please don't include complete copies of previous messages when
replying to an xmlroff-list post. The SourceForge archive puts
an entire thread on one HTML page, so the previous message is
visible to anyone using the archive, and including it again just
means people have to scroll past it to get to the following
message.
|
|
From: Charles B. <cbo...@hi...> - 2003-03-07 01:53:47
|
I think this is an excellent idea especially your idea of seeing the formated output in one pane and the FO and properties in another. I am discovering that it is difficult to determine if a fo has been rendered correctly; even a small fo has a lot of complexities. I also like the idea of having loadable modules to work at different stages of formatting. I can image not only being able to choose different output formats but also having a choice different algorithms during the adjustment phase. I've never worked on a GUI application before and I image this one is not too easy, but I'll bet it will pay off in the long run. On Thu, 2003-03-06 at 07:00, Tony Graham wrote: > Posted here and on the xmlroff Wiki to see which one generates the > most responses. > > Regards, > > > Tony Graham > ------------------------------------------------------------------------ > XML Technology Center - Dublin > Sun Microsystems Ireland Ltd Phone: +353 1 8199708 > Hamilton House, East Point Business Park, Dublin 3 x(70)19708 > > ------------------------------------------------------------ > FO and Area Tree Browser > > The xmlroff design calls for an 'Area Tree Adjust' stage after the > initial formatting is done and before the area tree is written out as > PDF, etc. > > The intent is to call loadable modules to do the work. > > An idea for an initial loadable module that doesn't actually adjust > the area tree is to make a graphical browser that shows the FO and > area trees. > > The browser would be: > > *proof-of-concept for the loadable module technique > *useful visualisation tool for XSL > *useful debugging aid > *basis for eventual manual area-tree-tweaker > > The current idea is a multi-pane or multi-window browser showing: > > *FO tree > *Properties of currently selected FO > *Areas generated by currently selected FO > *Area tree with currently selected area highlighted > *Properties of currently selected area > > In principle this could be extended to include panes or windows for: > > *Formatted output with currently selected area highlighted > *Input XML document(s) with element or attribute that generated > currently selected FO highlighted > > (All of which would really fuel the market for multi-head displays.) > > GNOME or GTK+ would be the obvious choice for windowing toolkit, but > it could instead be done in Tk or any of a number of other > technologies. > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger > for complex code. Debugging C/C++ programs can leave you feeling lost and > disoriented. TotalView can help you find your way. Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > xmlroff-list mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlroff-list -- Charles Bozeman <cbo...@hi...> |
|
From: Tony G. <Ton...@Su...> - 2003-03-06 13:00:51
|
Posted here and on the xmlroff Wiki to see which one generates the most responses. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 ------------------------------------------------------------ FO and Area Tree Browser The xmlroff design calls for an 'Area Tree Adjust' stage after the initial formatting is done and before the area tree is written out as PDF, etc. The intent is to call loadable modules to do the work. An idea for an initial loadable module that doesn't actually adjust the area tree is to make a graphical browser that shows the FO and area trees. The browser would be: *proof-of-concept for the loadable module technique *useful visualisation tool for XSL *useful debugging aid *basis for eventual manual area-tree-tweaker The current idea is a multi-pane or multi-window browser showing: *FO tree *Properties of currently selected FO *Areas generated by currently selected FO *Area tree with currently selected area highlighted *Properties of currently selected area In principle this could be extended to include panes or windows for: *Formatted output with currently selected area highlighted *Input XML document(s) with element or attribute that generated currently selected FO highlighted (All of which would really fuel the market for multi-head displays.) GNOME or GTK+ would be the obvious choice for windowing toolkit, but it could instead be done in Tk or any of a number of other technologies. |
|
From: Tony G. <Ton...@Su...> - 2003-03-05 17:00:16
|
xmlroff 0.2.2 is now available for download from http://sourceforge.net/project/showfiles.php?group_id=73148 Changes between 0.2.1 and 0.2.2: * Build fixes for handling dependency on libxml2 [Charles Bozeman] * Minor property code improvements * Increased documentation comment coverage Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
|
From: Tony G. <Ton...@Su...> - 2003-03-04 22:23:12
|
Charles Bozeman wrote at 3 Mar 2003 20:28:43 -0600: > As you can see from the error, the libxml2 include path does not get to the > compiler. If I add $(LIBXML_CFLAGS) to the INCLUDE makefile variable then > the compile works. From your email I see I should be using LIBXSLT_CFLAGS > but the result is the same. > Maybe I'm missing something but I don't see it. I think it's gcc saving me from myself. I will add the missing $(LIBXSLT_CFLAGS) entries. I plan to eventually not have every module dependent on libxml2. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
|
From: Tony G. <Ton...@Su...> - 2003-03-04 22:18:20
|
Charles Bozeman wrote at 3 Mar 2003 21:29:00 -0600: ... > Thanks for the hints. I found my problem is that some of my font files > (type1 pfa files) use '\r' instead of '\n' to end lines which caused > PDFlib to read (via fgets) too much data and process the font data That sounds like a PDFlib bug, but it could be argued that it's a problem with your file on a Unix system. > wrong. I've finally gotten the test file to work so maybe now I can be > somewhat productive. I just wish I had more time to spend on this > project, because I believe it is really important for xml processing to > progress. Thank you. I, too, would like to see XML processing -- in this context, XSL formatting -- progress. In fairness, xmlroff is not the only option, but right now it is the open-source option most in need of help. xmlroff does have more going for it than its need for help. AFAIK, it's the only open-source formatter written in C, and I believe that it is the formatter that places the highest priority on i18n. (Although I still haven't managed to get Thai or Arabic through PDFlib even though Pango can rasterize them nicely with its FT2 backend). Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
2 messages has been excluded from this view by a project administrator.
