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: Tim W. <tw...@re...> - 2005-03-13 12:32:23
|
On Sat, Mar 12, 2005 at 11:41:38PM +0000, Tony Graham wrote: > Tim Waugh <tw...@re...> writes: > ... > > But now xmlroff immediately segfaults. :-/ > > > > #0 0x069dd771 in gnome_print_job_print_to_file (job=3D0x0, > > output=3D0x8dd7768 "layout.pdf") at gnome-print-job.c:1181 > > #1 0x080af58e in fo_doc_gp_get_type () > > #2 0x00878b12 in g_object_unref () from /usr/lib/libgobject-2.0.so.0 > > #3 0x080ac00f in main () > > > > 0x069dd771 in gnome_print_job_print_to_file (job=3D0x0, > > output=3D0x8dd7768 "layout.pdf") at gnome-print-job.c:1181 > > 1181 gnome_print_config_set (job->config, "Settings.= Transport.Backend", "file"); >=20 > I have seen this recently, but none of the xmlroff testsuite files > fail this way, so I can't reproduce it. Can you provide yet another > FO file? Oddly enough, I can't get this to happen now. I'm afraid I didn't make a note of which FO file triggered it. :-( Tim. */ |
From: Tony G. <Ton...@Su...> - 2005-03-13 12:24:21
|
pca...@ca... writes: > Yes, i was referring to that kind of 'gibberish' (don't know that word > but sounds good to define the effect :) ) xmlroff isn't doing anything to garble the text. I've asked on the gnome-print list whether or not this is a feature of GNOME Print's PDF. Regards, Tony. |
From: Tony G. <Ton...@Su...> - 2005-03-12 23:41:16
|
Tim Waugh <tw...@re...> writes: ... > But now xmlroff immediately segfaults. :-/ > > #0 0x069dd771 in gnome_print_job_print_to_file (job=0x0, > output=0x8dd7768 "layout.pdf") at gnome-print-job.c:1181 > #1 0x080af58e in fo_doc_gp_get_type () > #2 0x00878b12 in g_object_unref () from /usr/lib/libgobject-2.0.so.0 > #3 0x080ac00f in main () > > 0x069dd771 in gnome_print_job_print_to_file (job=0x0, > output=0x8dd7768 "layout.pdf") at gnome-print-job.c:1181 > 1181 gnome_print_config_set (job->config, "Settings.Transport.Backend", "file"); I have seen this recently, but none of the xmlroff testsuite files fail this way, so I can't reproduce it. Can you provide yet another FO file? Regards, Tony. |
From: Tony G. <Ton...@Su...> - 2005-03-12 23:27:55
|
Julian Rosse <gn...@th...> writes: > Right now dump-info.xml has <property> tags (with only "name" attributes) > for shorthand > properties for seven of the eight absolute/relative sides - "border-bottom" is > missing. The XSL spec only seems to mention shorthands for the absolute > sides - border-bottom, border-top, border-left, border-right. Should the other > four exist? There seems to be code talking about border-after's and such in No, the other four shouldn't exist. I shouldn't have put them in dump-info.xml. > some of the area code, and the spec seems to talk about it in those terms, > but not for actual element attributes. Also, right now spec-dump doesn't seem > to include any of these properties in the files it dumps; I didn't see right > off what suppresses them. Selective patching on my part. > There are already fo-property-border.[ch] files which seem to have some > general border-oriented enums and such - will I want to merge these with the > same-named files that spec-dump will produce, or rename these existing files, > ...? You should be able to replace the files without a problem. At one time, all of the border-related enums were defined in fo-border.[ch] and all the border types were subclasses of FoBorder. That was too unwieldy and didn't reflect that fact that 'border' is itself a property. The enums have been superseded by the enums in datatype/fo-enum.[ch]. All enums are currently defined there both so a particular enum object is only created once and so there's less hassle in getting an enumerated value from a property of a different type using from-parent(), etc. The definitions of thin, medium, and thick borders have been superseded by functions in datatype/fo-length.[ch]. fo_property_border_resolve() has been moved to fo_property_util_border_resolve() and, thanks to you, has been significanlty updated. > A semantic question for which I didn't notice an answer in the spec right > off - the spec clearly says that the border-<side> shorthands are of higher > priority than border-{style,color,width}, and "border" is lowest priority. > You're allowed to omit any or all of the style, color, and width components > from the border{,-<side>} shorthands, right (I don't know the XSL spec regex > vocabulary particularly - ||, etc.)? e.g., border-top="1px solid" is valid, > no? In the case that components are omitted, it would seem intuitive that > any values already assigned by a lower-priority shorthand which correspond > to an omitted component on the current one would remain as the value, rather > than, say, a default value for that omitted component overriding the actually > specified value from a lower-priority shorthand. If that is the desired > semantics, how will that be represented in xmlroff? In particular, what will, > say, fo_wsc_get_color() return if that component was omitted from the > shorthand attribute corresponding to the FoWsc? I want to say NULL, but that > seems to indicate other error conditions - would we need some other enum value > meaning "omitted" or something? I guess that's somewhere > between a question and a suggestion. I was wondering much the same thing when I was implementing datatype/fo-wsc.[ch]. fo_wsc_new() creates an FoWsc with NULL for all three components, yet fo_wsc_new_from_values() will complain if you don't provide component values, so you can see I am conflicted about this. I had a whole different answer worked out, but it now seems to me that we should use NULL for a component that is not specified. Consider this: <fo:block border-color="red" border-left="thin solid"/> I think the result for the left/start border would be thin/solid/red rather than thin/solid/(text color). > If 'inherit' is specified on one of these shorthands, will that be resolved > in the expr-eval code? From my perspective, that will already be resolved > before the fo-context-util code gets ahold of the FoWsc's, right? The resolved value should be the value from the parent context. It will be resolved by the expr-eval code (once it's written). The fo-context-util code shouldn't have to worry about it. Good questions. Thanks. Regards, Tony. |
From: Julian R. <gn...@th...> - 2005-03-12 18:11:25
|
Hi, A couple questions I'm coming up with as I look at the "border" and border side shorthands: Right now dump-info.xml has <property> tags (with only "name" attributes) for shorthand properties for seven of the eight absolute/relative sides - "border-bottom" is missing. The XSL spec only seems to mention shorthands for the absolute sides - border-bottom, border-top, border-left, border-right. Should the other four exist? There seems to be code talking about border-after's and such in some of the area code, and the spec seems to talk about it in those terms, but not for actual element attributes. Also, right now spec-dump doesn't seem to include any of these properties in the files it dumps; I didn't see right off what suppresses them. There are already fo-property-border.[ch] files which seem to have some general border-oriented enums and such - will I want to merge these with the same-named files that spec-dump will produce, or rename these existing files, ...? A semantic question for which I didn't notice an answer in the spec right off - the spec clearly says that the border-<side> shorthands are of higher priority than border-{style,color,width}, and "border" is lowest priority. You're allowed to omit any or all of the style, color, and width components from the border{,-<side>} shorthands, right (I don't know the XSL spec regex vocabulary particularly - ||, etc.)? e.g., border-top="1px solid" is valid, no? In the case that components are omitted, it would seem intuitive that any values already assigned by a lower-priority shorthand which correspond to an omitted component on the current one would remain as the value, rather than, say, a default value for that omitted component overriding the actually specified value from a lower-priority shorthand. If that is the desired semantics, how will that be represented in xmlroff? In particular, what will, say, fo_wsc_get_color() return if that component was omitted from the shorthand attribute corresponding to the FoWsc? I want to say NULL, but that seems to indicate other error conditions - would we need some other enum value meaning "omitted" or something? I guess that's somewhere between a question and a suggestion. If 'inherit' is specified on one of these shorthands, will that be resolved in the expr-eval code? From my perspective, that will already be resolved before the fo-context-util code gets ahold of the FoWsc's, right? All I have for now.. Thanks, Julian |
From: Tim W. <tw...@re...> - 2005-03-12 14:00:42
|
On Fri, Mar 11, 2005 at 04:29:45PM +0000, Tony Graham wrote: > Does the current incantation manage to install libfo-compat.xsl, etc.? Yes, the spec file is fine now. But now xmlroff immediately segfaults. :-/ #0 0x069dd771 in gnome_print_job_print_to_file (job=0x0, output=0x8dd7768 "layout.pdf") at gnome-print-job.c:1181 #1 0x080af58e in fo_doc_gp_get_type () #2 0x00878b12 in g_object_unref () from /usr/lib/libgobject-2.0.so.0 #3 0x080ac00f in main () 0x069dd771 in gnome_print_job_print_to_file (job=0x0, output=0x8dd7768 "layout.pdf") at gnome-print-job.c:1181 1181 gnome_print_config_set (job->config, "Settings.Transport.Backend", "file"); Tim. */ |
From: Tony G. <Ton...@Su...> - 2005-03-12 10:02:20
|
Julian Rosse <gn...@th...> writes: ... > Speaking of the border properties, I'm thinking I should (sort of have to) > wait to do the > spec-dump/fo-context-util stuff until I know at least the names of the validate/ > resolve-enum functions that will go in dump-info.xml and the interface of the > new datatype. So once you are to that point, please let me know that stuff, and > I'll hit those tasks. Checked in last night, but I didn't have email access to let you know. The eval function just returns a constant value at present. Thanks for continuing to work on this. Regards, Tony. |
From: Julian R. <gn...@th...> - 2005-03-11 23:25:47
|
Hi, Tony Graham wrote: > You'd hope that someone in the GNOME ecosystem has written something > that can read in SVG and drive gnome-print from it. I'm curious. I noticed in poking around the libgnomeprint(-2.8.2) source code that they seem to have an SVG output backend. It looks like it's based in SVG 1.2 (still in some sort of draft stage, I think) - I saw some <page> tags floating around; this is probably what you were referring to for SVG page description. I don't know whether it works yet or what. I also found the question of whether SVG-to-gnome-print (as well as SVG-to-PS and SVG-to-PDF, among others) exists yet asked on the AbiWord mailing list a couple months ago; noone answered either way. If not, this sounds like something cool to me. > I have asked that you finish off the border properties, but you are > welcome to work on the graphics problem if you want. This is > voluntary open-source development on your part (and mine, these days) > which means you get to scratch where you have itches. I like the model we're working under, where you're dictating the order in which we do stuff and help split up the tasks - it'll certainly be a while until I'd be ready to tackle a large chunk without lots of help from you. If I want to tackle a project like the above (SVG to gnome-print or some such), I'll start doing it on my "own time" (that is, in addition to helping you with the stuff as you feel it should get done), and of course let people know if I'm doing anything substantial. At least, that's how I feel about it now :). It wouldn't make much sense for me to do anything at this point that would probably just end up interfering with the plans you have for external-graphic and instream-foreign-object. Hopefully that works for you. Speaking of the border properties, I'm thinking I should (sort of have to) wait to do the spec-dump/fo-context-util stuff until I know at least the names of the validate/ resolve-enum functions that will go in dump-info.xml and the interface of the new datatype. So once you are to that point, please let me know that stuff, and I'll hit those tasks. Thanks, Julian |
From: Tim W. <tw...@re...> - 2005-03-11 19:01:29
|
On Fri, Mar 11, 2005 at 04:29:45PM +0000, Tony Graham wrote: > Does the current incantation manage to install libfo-compat.xsl, etc.? I think anoncvs takes a day or so to update. I'll let you know. Tim. */ |
From: Tony G. <Ton...@Su...> - 2005-03-11 16:29:27
|
Tim Waugh <tw...@re...> writes: > I had to change xmlroff.spec to add this line: > > %{_datadir}/xml/libfo-*/ > > to the %files section, to prevent the package build failing with an > 'unpackaged files' error. I've added that change and the other change you posted. I will check them in later today. You know my opinion of RPM spec files. Can you post a contextual diff the next time you need to fix something? Does the current incantation manage to install libfo-compat.xsl, etc.? Regards, Tony. |
From: Tony G. <Ton...@Su...> - 2005-03-11 16:20:18
|
Tim Waugh <tw...@re...> writes: > One of the changes I had to make to get xmlroff to build on Fedora > Core using 'rpmbuild -tb xmlroff-0.3.2.tar.gz' was to change this line > in the spec file: > > BuildRequires: libgnomeprint28-devel > > to read: > > BuildRequires: libgnomeprint22-devel > > Is there a particular reason that libgnomeprint28-devel was put there > in the first place? The numbers are meant to be the soname (2.2), not Ignorance? > the major version of the source code (2.8). I'll change it. Regards, Tony. |
From: Tim W. <tw...@re...> - 2005-03-11 14:28:52
|
I had to change xmlroff.spec to add this line: %{_datadir}/xml/libfo-*/ to the %files section, to prevent the package build failing with an 'unpackaged files' error. Tim. */ |
From: Tim W. <tw...@re...> - 2005-03-11 14:26:23
|
One of the changes I had to make to get xmlroff to build on Fedora Core using 'rpmbuild -tb xmlroff-0.3.2.tar.gz' was to change this line in the spec file: BuildRequires: libgnomeprint28-devel to read: BuildRequires: libgnomeprint22-devel Is there a particular reason that libgnomeprint28-devel was put there in the first place? The numbers are meant to be the soname (2.2), not the major version of the source code (2.8). Tim. */ |
From: Tim W. <tw...@re...> - 2005-03-11 11:06:54
|
On Thu, Mar 10, 2005 at 11:16:09PM +0000, Tony Graham wrote: > I would like to be able to say that in principle the return_child > should not be null, but it's been so long that I can't be sure. > Obviously it is null in that instance. FWIW, making the change I suggested does seem to fix the segfault, although some parts of the output seem to be on the wrong page (in particular a white-space-treatment='preserve' figure seems to have been split across to pages, both parts being at the top of the page) . Not sure if that's a separate problem. > Can you send me your file, although I can't say when I will get to > look at it. [Sent in private mail.] Tim. */ |
From: Tony G. <Ton...@Su...> - 2005-03-10 23:15:51
|
Tim Waugh <tw...@re...> writes: > On Thu, Mar 10, 2005 at 04:49:06PM +0000, Tim Waugh wrote: > >> That's what I tried to start with, and it gets me a segfault. :-) > > Here's where it faults, by the way: > > #0 0x080bd4da in fo_area_size_request_default (child=0xa62ac18) > at fo-area.c:1985 > 1985 while (return_child->next_part != child_original_next_part) > > return_child is 0x0, child is 0xa62ac18 and child_original_next_part > is 0xa535e58. > > Looks like it probably needs to be something like > > while (return_child->next_part && return_child->next_part != ...) I would like to be able to say that in principle the return_child should not be null, but it's been so long that I can't be sure. Obviously it is null in that instance. Can you send me your file, although I can't say when I will get to look at it. Regards, Tony. |
From: Tony G. <Ton...@Su...> - 2005-03-10 22:43:09
|
Julian Rosse <gn...@th...> writes: > What are your thoughts on supporting SVG instream-foreign-objects? I have I'm in favour of it. FOP, for example, does it. I'd like to get external-graphic working again (and working the "correct" way from my other mail of today) first. > been thinking that would be a cool longer-term goal, and an itch that I'd > eventually like to scratch. I was doing a bit of reading - there's this > librsvg associated with GNOME which dumps GdkPixBufs; when I googled svg to xmlroff uses Pango to lay out blocks of text. fo:external-graphic and fo:instream-foreign-object are both "inline" formatting objects in that they "generate and return" inline areas. The technique that I want to continue using for fo:external-graphic is to tell Pango the size of the graphic (using Pango's standard "PangoAttrShape" ) and provide a callback (using PangoXSL's non-standard and currently no longer implemented "callback" attribute) for doing the rendering of the graphic. As it used to work in PangoPDF, when Pango (actually PangoPDF at the time) renders the run containing the shape and callback attributes, the processing for the callback attribute places the "current point" of the rendering context at the top-left corner (at a known corner, anyway) and calls the callback. The code in the callback does the work of writing the image to the rendering context. In PangoPDF, it used the PDFlib functions for writing images to the PDF output. When re-implemented for GNOME Print, it will use the GNOME Print functions for writing images to the output. Given that, there isn't much difference between an external-graphic and an SVG instream-foreign-object if you have a library that can covert the SVG into a format that can be passed to a rendering function as part of the callback processing. > postscript, I found a discussion on an XSL-FO mailing list about the subject > which you were part of (you mentioned xslfo-proc -> now dandy - I couldn't > really tell what its deal is from its website) - but you guys seemed to be > saying "hmm that should be pretty easy but is there such a tool?" or "maybe > people will start using SVG as a page description language instead of PS or > PDF". As I remember it, xslfo-proc (or xslfoproc) was going to use SVG as its hub output format from which would be produced other formats such as PDF. I don't follow SVG very much, but I believe that a recent version has made it much easier to write a sequence of SVG pages. When I first looked at SVG, an SVG document was one image and if you wanted a sequence of page images, you'd have had to invent your own element to wrap a sequence of SVG elements. > I'm sure you have ideas about the subject - what are they? I'm not trying I have a few... There's at least four ways to hook SVG and XSL FO together: - Use SVG as an instream-foreign-object format, as you've discussed. - Use SVG as an output format or the output format from the formatter. - Use SVG (or something based on SVG) as the hub output format from which are produced other output formats. - Use SVG (or something based on SVG) as the internal area tree format/model. That last one always sounds intriguing at first, but in xmlroff, most of the properties that you'd think of as being in an SVG-like model -- such as font sizes, colours, etc. -- only ever exist in the FO tree and are copied from the FO tree only when writing the output to a file. SVG as an output format would be interesting, and I have sometimes thought of writing a Pango backend (or are they Pango renderers these days?) for SVG if I had infinite time to spare. You could do something SVG-like as an area tree output format that could be written out and read back in to recreate area trees, but I've never found a convincing reason to do that. I find that the line-based format from "xmlroff -d4" is usually sufficient for debugging areas and is probably easier to read than if it were XML. If xmlroff develops to the point of needing to serialize layouts or even pages to free up memory when processing large documents, then you'd pick a format that's quick to write out and quick to read back in, and I don't know that that would be SVG or even XML since we're not talking interchange at that point. > to jump into a huge undertaking after just submitting a couple patches - just > getting excited about a possible longer term goal. Would an SVG "rendering" > library on top of gnome-print make any sense? BTW I still have little to no You'd hope that someone in the GNOME ecosystem has written something that can read in SVG and drive gnome-print from it. > idea what I'm talking about regarding most of these things - so feel free to > tell me I'm being stupid. You're not being stupid. I have asked that you finish off the border properties, but you are welcome to work on the graphics problem if you want. This is voluntary open-source development on your part (and mine, these days) which means you get to scratch where you have itches. Regards, Tony. |
From: Tim W. <tw...@re...> - 2005-03-10 18:22:42
|
On Thu, Mar 10, 2005 at 04:49:06PM +0000, Tim Waugh wrote: > That's what I tried to start with, and it gets me a segfault. :-) Here's where it faults, by the way: #0 0x080bd4da in fo_area_size_request_default (child=0xa62ac18) at fo-area.c:1985 1985 while (return_child->next_part != child_original_next_part) return_child is 0x0, child is 0xa62ac18 and child_original_next_part is 0xa535e58. Looks like it probably needs to be something like while (return_child->next_part && return_child->next_part != ...) Tim. */ |
From: Tony G. <Ton...@Su...> - 2005-03-10 18:02:56
|
Tim Waugh <tw...@re...> writes: > On Thu, Mar 10, 2005 at 04:41:49PM +0000, Tony Graham wrote: .. > Oh, now that I look more closely, it's the fo:external-graphic ones I > wanted. The background-image things were for 'draft'-type watermarks, > and they come from docbook-xsl. > > So is that more difficult? Oh, yes. The simple answer: - Implement the graphic handing in FoDocGP that used to be in FoDocPDF. - Modify PangoXSL to walk the PangoLayout after it's been rendered and call the callback for each graphic. The correct answer: - Rewrite the "inline" FOs so they create areas (rather than, as at present, their containing FoBlock walks the FO tree to build a PangoAttribute list). - Make the FoAreaLayout walk its contained areas to build the PangoLayout. - Make an FoAreaGraphic that holds the callback for printing the graphic. - Modify PangoXSL to walk the PangoLayout after it's been rendered and call the callback for each graphic. - Submit a Pango enhancement request once the callback technique is shown to work so the callback handling goes into core Pango. - Make an FoImage datatype (or similar) so you don't have to have multiple copies of a graphic file when there's multiple references to the same external graphic. Regards, Tony. |
From: Tony G. <Ton...@Su...> - 2005-03-10 17:48:52
|
Tim Waugh <tw...@re...> writes: ... > It's because sprintf is a macro (I have -D_FORTIFY_SOURCE=2 in my > CFLAGS). > > Names of C functions that may be implemented as macros cannot be used > as user functions or variables, and that includes this struct member. > > I think it needs to be changed to something other than 'sprintf'. Changed to 'print_sprintf' (which parallels existing 'debug_sprintf' name). Regards, Tony. |
From: <pca...@ca...> - 2005-03-10 17:23:40
|
To Tony: Yes, i was referring to that kind of 'gibberish' (don't know that word but sounds good to define the effect :) ) To Tim and Tony, Find attached to this email, two files used to produce a PDF file I can't search in. Note: using xsltproc and fop on these two files makes a PDF file I can search in (and copy paste too). Thanks, Phil. |
From: Tim W. <tw...@re...> - 2005-03-10 16:49:13
|
On Thu, Mar 10, 2005 at 04:41:49PM +0000, Tony Graham wrote: > For @white-space-treatment="preserve", modify your whitespace munging > template to not apply to FOs with @white-space-treatment="preserve". > xmlroff preserves whitespace by default. That's what I tried to start with, and it gets me a segfault. :-) > @background-image would probably be pretty simple (much simpler than > fo:external-graphic): in theory, you'd modify area-to-pdf.c to do > the FoDoc calls to render the background image before doing the > FoDoc calls to render the text. You may also have to implement > FoDocGP functions to render the image, but how hard can that be? Oh, now that I look more closely, it's the fo:external-graphic ones I wanted. The background-image things were for 'draft'-type watermarks, and they come from docbook-xsl. So is that more difficult? Tim. */ |
From: Tony G. <Ton...@Su...> - 2005-03-10 16:42:02
|
Tim Waugh <tw...@re...> writes: > So I managed to get a DocBook document converted to PDF using xmlroff > and the libfo-compat.xsl stylesheet (with the two modifications I > posted) applied to docbook-xsl output, and I'm really impressed. Music to my ears. > The two immediately obvious things missing are: > > * PNG graphics (@background-image) > * @white-space-treatment="preserve" for DocBook <screen> nodes > > The only other thing wrong with the output for this document is that > an <orderedlist> comes out as a weird array of dots instead of any > text. I haven't been able to make a smaller test case yet. > > What steps are needed to add @background-image and > @white-space-treatment support? For @white-space-treatment="preserve", modify your whitespace munging template to not apply to FOs with @white-space-treatment="preserve". xmlroff preserves whitespace by default. @background-image would probably be pretty simple (much simpler than fo:external-graphic): in theory, you'd modify area-to-pdf.c to do the FoDoc calls to render the background image before doing the FoDoc calls to render the text. You may also have to implement FoDocGP functions to render the image, but how hard can that be? Regards, Tony. |
From: Tony G. <Ton...@Su...> - 2005-03-10 16:21:10
|
Tim Waugh <tw...@re...> writes: > On Thu, Mar 10, 2005 at 12:34:23AM +0000, Tony Graham wrote: > >> Thanks, but instead I added <xsl:preserve-space> and listed all the >> FOs with #PCDATA in their content model. Please confirm whether or >> not that does the job. > > It doesn't. I get things like this: > > press<fo:inline font-weight="bold">F8</fo:inline>for the menu > > from a DocBook para fragment that had: > > press <keycap>F8</keycap> > for the menu This template rule may be the problem: <xsl:template match="text()"> <xsl:value-of select="normalize-space()"/> </xsl:template> The real problem, for xmlroff, is the whitespace at the beginning of the lines. I'll look again at your whitespace patch. >> or the FoLibfoContext warning mode setting could actually be >> implemented. > > What would be the effect of that? Whatever we want, not least because (a) it's software, and (b) it's software that hasn't been written yet. I was contemplating a warning mode setting to not warn about unsupported properties. Just because I find it useful to be warned about unsupported properties doesn't mean everybody else does. Regards, Tony. |
From: Tim W. <tw...@re...> - 2005-03-10 16:13:28
|
So I managed to get a DocBook document converted to PDF using xmlroff and the libfo-compat.xsl stylesheet (with the two modifications I posted) applied to docbook-xsl output, and I'm really impressed. The two immediately obvious things missing are: * PNG graphics (@background-image) * @white-space-treatment="preserve" for DocBook <screen> nodes The only other thing wrong with the output for this document is that an <orderedlist> comes out as a weird array of dots instead of any text. I haven't been able to make a smaller test case yet. What steps are needed to add @background-image and @white-space-treatment support? Tim. */ |
From: Tim W. <tw...@re...> - 2005-03-10 15:55:43
|
On Thu, Mar 10, 2005 at 12:34:23AM +0000, Tony Graham wrote: > Thanks, but instead I added <xsl:preserve-space> and listed all the > FOs with #PCDATA in their content model. Please confirm whether or > not that does the job. It doesn't. I get things like this: press<fo:inline font-weight="bold">F8</fo:inline>for the menu from a DocBook para fragment that had: press <keycap>F8</keycap> for the menu > or the FoLibfoContext warning mode setting could actually be > implemented. What would be the effect of that? Tim. */ |