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...> - 2006-01-27 20:53:14
|
"Gerrit P. Haase" <ge...@fa...> writes: > - Emacs / Xemacs integration. What do you mean? If you use my xslide XSL mode, you could setup xmlroff as one of the XSL processor options. > - OpenOffice integration Why not just create PDF using OpenOffice? > - More editor integration (Nedit, ....) What do you mean? I would advise creating XML using a vocabulary that means something to you, rather than writing in the presentation-oriented XSL-FO vocabulary. > - Standalone FOP editor with xmlroff integration? Do you mean "FO"? FOP is an XSL formatter written in Java. > So I could edit a FOP document and with one click I get the PDF. But, again, I question why you would create documents in the XSL-FO category. Regards, Tony. |
|
From: Tony G. <Ton...@Su...> - 2006-01-27 20:47:24
|
Aron Stansvik <elv...@gm...> writes: > 2006/1/27, Tony Graham <Ton...@su...>: > ... >> - Rewrite in a more OO language >> >> - Rewrite in... > > Do you have any specific language in mind? I'm just asking because > your e-mail just popped up as I was reading about the D programming > language* which looks quite interesting. No, I don't have any specific language in mind. I was just fishing for people's thoughts. D does look cool, and I would dearly love native OO and garbage collection, but it wouldn't be a good fit if the intention is for xmlroff to be GNOME-like. It would be fun, but a big diversion, to write spec-dump XSL files to produce D code instead of C code. Regards, Tony. > * http://www.digitalmars.com/d/ |
|
From: Gerrit P. H. <ge...@fa...> - 2006-01-27 18:41:49
|
Aron schrieb: > 2006/1/27, Tony Graham <Ton...@su...>: > ... >> - Rewrite in a more OO language >> >> - Rewrite in... > Do you have any specific language in mind? I'm just asking because > your e-mail just popped up as I was reading about the D programming > language* which looks quite interesting. > Best regards, > Aron Stansvik > * http://www.digitalmars.com/d/ IMO rewriting is not neccessary. Isn't it already written in the most portable language? I prefer xmlroff over all other solutions because it is not Java like all the other solutions. Gerrit -- =^..^= |
|
From: Gerrit P. H. <ge...@fa...> - 2006-01-27 18:40:14
|
- Emacs / Xemacs integration. - OpenOffice integration - More editor integration (Nedit, ....) - Standalone FOP editor with xmlroff integration? So I could edit a FOP document and with one click I get the PDF. Gerrit -- =^..^= |
|
From: Aron S. <elv...@gm...> - 2006-01-27 17:52:19
|
2006/1/27, Tony Graham <Ton...@su...>: ... > - Rewrite in a more OO language > > - Rewrite in... Do you have any specific language in mind? I'm just asking because your e-mail just popped up as I was reading about the D programming language* which looks quite interesting. Best regards, Aron Stansvik * http://www.digitalmars.com/d/ |
|
From: Tony G. <Ton...@Su...> - 2006-01-27 17:27:20
|
I was thinking about what next to do for xmlroff, then I got to thinking of asking you people what to do next for xmlroff, then I ended up deciding to ask about the big picture for xmlroff. I would define the purpose of the xmlroff project as: To develop an open source, conformant, multilingual XSL formatter capable of producing printable output from XML for most technical and business documents. The project's principles are: - xmlroff should be free. - There's room in this world for more than one open source XSL formatter. - There's room in this world for open-source, free but not open, and commercial XSL formatters. It's been a while since I've had this sort of conversation with myself, let alone with anybody else, and I surprised myself by not mentioning C or GNOME. Given the above, a successful outcome for the project would be: A multilingual XSL formatter with conformantly implements the formatting objects and properties necessary for formatting most technical and business documents. Nobody is going to tell you that the current xmlroff represents that successful outcome. Opinions on the purpose, principles, outcome, etc., of the project are welcome, but if the definition of a successul outcome is sufficiently accurate for your purposes, my question is: What needs to be done to make xmlroff a success? To brainstorm for a moment, ideas that come to mind include: - Implement region-before, region-after, etc. - Implement markers - Provide RPMs as well as SRPMs and .tar.gz downloads - Provide a Windows port - Improve developer documentation - Improve end-user documentation - Rewrite in a more OO language - Rewrite in... - Sack the maintainer - Put the statement of purpose on the xmlroff web page Any and all ideas are welcome at this point. We can categorise and organise the ideas later. Regards, Tony. |
|
From: Tony G. <Ton...@Su...> - 2005-12-07 15:15:29
|
xmlroff 0.3.8 is now available from the new-look http://sourceforge.net/projects/xmlroff. xmlroff 0.3.8 is more stable since it now correctly handles areas too big to fit on the page and fixes the bug that Stefan found after that. Error handling is improved since xmlroff now stops at the first error instead of continuing. Stopping at the first error means fewer segfaults, which should please most people. I will be adding an option to xmlroff to continue processing after an error occurs, since it is more useful to me to have it do that. There will not be an xmlroff release "on or about" 1st January since I will be on vacation in Japan. Regards, Tony. ------------------------------------------------------------ Notes: Changes between 0.3.7 and 0.3.8 * Corrected endless loop if area won't fit on page * Added handling 'overflow' property of fo:region-body * xmlroff stops at first error instead of continuing ------------------------------------------------------------ Changes: 2005-12-06 Tony Graham <ton...@us...> * === Released 0.3.8 === * NEWS: Updated for 0.3.8. * xmlroff.c: Changed some error handling from g_message() to g_error(). * fo/fo-fo.c, result-to-fo.c: Turned some fo_object_log_or_propagate_error() calls into g_propagate_error() (for the moment, at least). * fo-node.c: Added fo_node_log_or_propagate_error(). * fo/fo-root.c: Minor corrections to an error message. * fo/fo-table.c: Made fo_table_span_info_debug_dump() non-static since prototype is in fo-table.h. * property/fo-property-display-align.c, property/fo-property-display-align.h, property/fo-property-height.c, property/fo-property-height.h, property/fo-property-score-spaces.c, property/fo-property-score-spaces.h, property/fo-property-source-document.c, property/fo-property-source-document.h, property/fo-property-wrap-option.c, property/fo-property-wrap-option.h: Updated to remove property-specific enums and to match current spec-dump. 2005-11-23 Tony Graham <ton...@us...> * result-to-fo.c, fo/fo-fo.c: Connected together more error reporting and propagating errors. * fo/fo-flow.c: Added error if 'flow-name' is NULL. Updated to match current spec-dump. * fo-object.c, fo-object.h: Added log_or_propagate_error class method. * fo-node.h: Added comments about FoNode and FoNodeClass structs. * datatype/fo-length.h: Updated copyright years. * fo/fo-static-content.c, fo/fo-static-content.h: Updated to match current spec-dump. * fo/fo-flow-private.h, fo/fo-flow.h: Updated to match current spec-dump. * fo/fo-fo.h: Added FO_FO_ERROR_DATATYPE_NULL error type. 2005-11-20 Tony Graham <ton...@us...> * area/fo-area-spanning-table-cell.c, area/fo-area-table-cell.c, area/fo-area-table-continuation.c, area/fo-area-table.c, area/fo-area.c: Added extra 'return_child->next_part != NULL' condition when finding which child area to return after a split. * area-to-pdf.c: Changed 'overflow' values for which to clip region-body. * result-to-fo.c: Added more comments and doc comments. * fo/fo-table-part.c, fo/fo-table.c, fo/fo-tree.c: Added doc comments. 2005-11-10 Tony Graham <ton...@us...> * area/fo-area-page.c, area/fo-area-page.h: Added fo_area_page_error_quark, etc., and made message when child area overflows into a warning, not g_critical message. * fo-node.c: Added fo_node_log_warning(). 2005-11-09 Tony Graham <ton...@us...> * area-to-pdf.c: Added clipping of FoAreaViewportReference if 'overflow' property value is not 'visible'. * area/fo-area-page.c: Now setting available height of area that can't be split. 2005-11-04 Tony Graham <ton...@us...> * configure.in: Upped version to 0.3.8. * area/fo-area-page.c: Added setting size and position of unsplittable FoAreaViewportReference. * datatype/fo-id.c, datatype/fo-id.h: Added fo_id_new_with_value(). Added doc comments. * datatype/fo-length-bp-ip-d.c: Fixed a doc comment. * fo/fo-repeatable-page-master-alternatives.c, fo/fo-repeatable-page-master-alternatives.h: Updated to match current spec-dump. * fo/Makefile.am, fo/fo-repeatable-page-master-alternatives-private.h: Added fo-repeatable-page-master-alternatives-private.h. * libfo/fo-layout.c: Doc comment changes/additions. * property/fo-property-overflow.c, property/fo-property-overflow.h: Updated to match current spec-dump. 2005-11-03 Stefan Seefeld * libfo-compat.xsl: Fix typos. |
|
From: Tony G. <Ton...@Su...> - 2005-11-20 17:34:24
|
Stefan Seefeld <se...@sy...> writes: > Tony Graham wrote: >> I believe I have fixed that bug: the sample file that you sent me now formats. >> My changes are checked in to CVS. Please try again. > > I did, and it generated a pdf indeed. That's great progress ! > I now see a lot of errors of the form > > (process:27427): GnomePrint-CRITICAL **: file gnome-print-stdapi.c: line 908 > (gnome_print_glyphlist): assertion `gp_gc_has_currentpoint (pc->gc)' failed > > What is that ? What does 'gc' stand for ? garbage collection ? graphic context ? :-) GNOME Print graphic context. Running your T.fo, I don't get any error messages at all. > Incidentally, I don't see any images in the pdf (I believe I had seen them prior to > this last change). May that be related ? It could be related, however the error that you show is from trying to print a PangoLayout. It may be related to the changes in area-to-pdf.c to support clipping the region-body FoAreaViewportReference for certain values of 'overflow', since I also just checked in changes to that. Regards, Tony. |
|
From: Stefan S. <se...@sy...> - 2005-11-20 15:51:18
|
Tony Graham wrote: > I believe I have fixed that bug: the sample file that you sent me now formats. > > My changes are checked in to CVS. Please try again. I did, and it generated a pdf indeed. That's great progress ! I now see a lot of errors of the form (process:27427): GnomePrint-CRITICAL **: file gnome-print-stdapi.c: line 908 (gnome_print_glyphlist): assertion `gp_gc_has_currentpoint (pc->gc)' failed What is that ? What does 'gc' stand for ? garbage collection ? graphic context ? :-) Incidentally, I don't see any images in the pdf (I believe I had seen them prior to this last change). May that be related ? Thanks ! Stefan |
|
From: Tony G. <Ton...@Su...> - 2005-11-20 14:46:22
|
Tony Graham <Ton...@Su...> writes: > Stefan Seefeld <se...@sy...> writes: ... >> 0x005a291a in fo_area_size_request_default (child=0x9458540) at fo-area.c:2063 >> >> (the rhs 'return_child' is 0x0, and so dereferencing next_part crashes the application) >> >> Let me know if I should mail you the full stack trace. > > It would be better to send me the FO file. > > BTW, I'm back to not having much time for xmlroff until the weekend: no train > journeys in the next couple of days, then a nine-hour flight on Saturday. I believe I have fixed that bug: the sample file that you sent me now formats. My changes are checked in to CVS. Please try again. Regards, Tony. |
|
From: Tony G. <Ton...@Su...> - 2005-11-10 15:52:03
|
Anybody else on this list going to XML 2005 next week? Regards, Tony. |
|
From: Tony G. <Ton...@Su...> - 2005-11-10 15:29:31
|
Stefan Seefeld <se...@sy...> writes: > Tony Graham wrote: >> Stefan Seefeld <se...@sy...> writes: ... >>>Let me know if I can help debug this further. >> Please correct your <uri-specification> and, if necessary, try it with a PNG >> instead of SVG image. > > Ok, I tuned the xslt stylesheet a bit and now I only get the first two libfo-CRITICAL > errors (warnings). However, xmlroff still segfaults: Now the messages really are warnings, but you'll still get them regardless of the 'overflow' property value. > 0x005a291a in fo_area_size_request_default (child=0x9458540) at fo-area.c:2063 > > (the rhs 'return_child' is 0x0, and so dereferencing next_part crashes the application) > > Let me know if I should mail you the full stack trace. It would be better to send me the FO file. BTW, I'm back to not having much time for xmlroff until the weekend: no train journeys in the next couple of days, then a nine-hour flight on Saturday. Regards, Tony. |
|
From: Stefan S. <se...@sy...> - 2005-11-10 14:57:19
|
Tony Graham wrote:
> Stefan Seefeld <se...@sy...> writes:
>
>>Tony Graham wrote:
>
> ...
>
>>I get a segmentation fault after lots of 'libfo-CRITICAL' messages. The first
>>one is
>>
>>(process:12015): libfo-CRITICAL **: fo_area_page_size_request:: Cannot split child:: page:
>>FoAreaPage (0x9e8ddb8 : 2); child: FoAreaViewportReference (0x9e8dcb8 : 1)
>>
>>which I assume your latest work was meant to resolve. Right ?
>
>
> I had left the warning in there so I could see when the code was being used.
> It is currently benign. I should change it to be a warning that is output
> only if the 'overflow' property value is 'error-if-overflow'.
>
>
>>The second such message looks like an identical copy of the first, but the third
>>one is strange again:
>
>
> That hopefully indicates that you have two pages with content that is too big
> for the page (or you added content to an area that was already too big for the
> page).
>
>
>>(process:12015): libfo-CRITICAL **: Expression evaluation error: Expression not completely
>>evaluated: '/ast.svg'
>>Object path:
>>/FoTree[1]/root[1]/page-sequence[5]/flow[1]/FoBlockBlock[2]/FoBlockLayout[3]/external-graphic[1]
>>
>>The expression in question seems to stem from an external-graphic attribute
>>src="images/ast.svg". I thought xmlroff is able to deal with such paths. Do I remember
>>wrongly ?
>
>
> I think you remember wrongly. The value of 'src' should be a
> <uri-specification>, which should start with 'url(' and end with ')'.
>
> You can submit an RFE for xmlroff to support 'src' property values without the
> 'url(...)'. All it would take would be yet another expression evaluation
> function, since "images/ast.svg" is a plausible expression.
>
> I don't know that xmlroff supports SVG graphics. I haven't tried it.
>
>
>>The last errors, which appear to have caused the actual segfault, are assertion errors
>>such as:
>>
>>(process:12015): libfo-CRITICAL **: file fo-length.c: line 320 (fo_length_get_value): assertion
>>`length != NULL' failed
>
>
> This may be a byproduct of the external graphic not being created properly.
> It indicates a bug in the error handling previously, since it shouldn't have
> got to the point of trying to process null length datatypes.
>
>
>>Let me know if I can help debug this further.
>
>
> Please correct your <uri-specification> and, if necessary, try it with a PNG
> instead of SVG image.
Ok, I tuned the xslt stylesheet a bit and now I only get the first two libfo-CRITICAL
errors (warnings). However, xmlroff still segfaults:
0x005a291a in fo_area_size_request_default (child=0x9458540) at fo-area.c:2063
(the rhs 'return_child' is 0x0, and so dereferencing next_part crashes the application)
Let me know if I should mail you the full stack trace.
Regards,
Stefan
|
|
From: Tony G. <Ton...@Su...> - 2005-11-10 11:03:43
|
Stefan Seefeld <se...@sy...> writes:
> Tony Graham wrote:
...
> I get a segmentation fault after lots of 'libfo-CRITICAL' messages. The first
> one is
>
> (process:12015): libfo-CRITICAL **: fo_area_page_size_request:: Cannot split child:: page:
> FoAreaPage (0x9e8ddb8 : 2); child: FoAreaViewportReference (0x9e8dcb8 : 1)
>
> which I assume your latest work was meant to resolve. Right ?
I had left the warning in there so I could see when the code was being used.
It is currently benign. I should change it to be a warning that is output
only if the 'overflow' property value is 'error-if-overflow'.
> The second such message looks like an identical copy of the first, but the third
> one is strange again:
That hopefully indicates that you have two pages with content that is too big
for the page (or you added content to an area that was already too big for the
page).
> (process:12015): libfo-CRITICAL **: Expression evaluation error: Expression not completely
> evaluated: '/ast.svg'
> Object path:
> /FoTree[1]/root[1]/page-sequence[5]/flow[1]/FoBlockBlock[2]/FoBlockLayout[3]/external-graphic[1]
>
> The expression in question seems to stem from an external-graphic attribute
> src="images/ast.svg". I thought xmlroff is able to deal with such paths. Do I remember
> wrongly ?
I think you remember wrongly. The value of 'src' should be a
<uri-specification>, which should start with 'url(' and end with ')'.
You can submit an RFE for xmlroff to support 'src' property values without the
'url(...)'. All it would take would be yet another expression evaluation
function, since "images/ast.svg" is a plausible expression.
I don't know that xmlroff supports SVG graphics. I haven't tried it.
> The last errors, which appear to have caused the actual segfault, are assertion errors
> such as:
>
> (process:12015): libfo-CRITICAL **: file fo-length.c: line 320 (fo_length_get_value): assertion
> `length != NULL' failed
This may be a byproduct of the external graphic not being created properly.
It indicates a bug in the error handling previously, since it shouldn't have
got to the point of trying to process null length datatypes.
> Let me know if I can help debug this further.
Please correct your <uri-specification> and, if necessary, try it with a PNG
instead of SVG image.
Regards,
Tony.
|
|
From: Stefan S. <se...@sy...> - 2005-11-10 02:03:53
|
Tony Graham wrote: > Tony Graham <Ton...@Su...> writes: > ... > >>xmlroff 0.3.7 fulfills the letter of Stefan's request that xmlroff not go into >>an infinite loop when it can't fit something on a page. xmlroff doesn't go >>into an infinite loop anymore; it just happens to not render the problematic >>area at all. >> >>Unfortunately, I won't have much time to work on xmlroff until at least the >>middle of the month, so if there was going to be a monthly release for >>November, this was the best I can do. > > > I had some time on the train into the office (which is how I get most of the > time that I can spend on xmlroff), and both got the problematic overflowing > area to render and implemented the 'overflow' property for region-body so the > overflowing area can be clipped. > > Please try the current code in CVS to see whether it is functional enough to > be worth making another release. I get a segmentation fault after lots of 'libfo-CRITICAL' messages. The first one is (process:12015): libfo-CRITICAL **: fo_area_page_size_request:: Cannot split child:: page: FoAreaPage (0x9e8ddb8 : 2); child: FoAreaViewportReference (0x9e8dcb8 : 1) which I assume your latest work was meant to resolve. Right ? The second such message looks like an identical copy of the first, but the third one is strange again: (process:12015): libfo-CRITICAL **: Expression evaluation error: Expression not completely evaluated: '/ast.svg' Object path: /FoTree[1]/root[1]/page-sequence[5]/flow[1]/FoBlockBlock[2]/FoBlockLayout[3]/external-graphic[1] The expression in question seems to stem from an external-graphic attribute src="images/ast.svg". I thought xmlroff is able to deal with such paths. Do I remember wrongly ? The last errors, which appear to have caused the actual segfault, are assertion errors such as: (process:12015): libfo-CRITICAL **: file fo-length.c: line 320 (fo_length_get_value): assertion `length != NULL' failed Let me know if I can help debug this further. Thanks, Stefan |
|
From: Tony G. <Ton...@Su...> - 2005-11-10 00:05:55
|
Tony Graham <Ton...@Su...> writes: ... > xmlroff 0.3.7 fulfills the letter of Stefan's request that xmlroff not go into > an infinite loop when it can't fit something on a page. xmlroff doesn't go > into an infinite loop anymore; it just happens to not render the problematic > area at all. > > Unfortunately, I won't have much time to work on xmlroff until at least the > middle of the month, so if there was going to be a monthly release for > November, this was the best I can do. I had some time on the train into the office (which is how I get most of the time that I can spend on xmlroff), and both got the problematic overflowing area to render and implemented the 'overflow' property for region-body so the overflowing area can be clipped. Please try the current code in CVS to see whether it is functional enough to be worth making another release. Regards, Tony. |
|
From: Stefan S. <se...@sy...> - 2005-11-03 00:28:41
|
Tony Graham wrote: > Stefan Seefeld <se...@sy...> writes: > >>The libfo-compat.xsl file contains a number of typos, which >>the attached patch tries to fix. > > > Thanks. I'll commit the change shortly (or you can do it). Done. Regards, Stefan |
|
From: Tony G. <Ton...@Su...> - 2005-11-02 23:25:27
|
Stefan Seefeld <se...@sy...> writes: > Tony Graham wrote: >> xmlroff 0.3.7 is now available from http://sourceforge.net/projects/xmlroff. >> This is a development snapshot, to put it politely, so there's a release "on >> or about the first of the month". >> xmlroff 0.3.7 fulfills the letter of Stefan's request that xmlroff not go >> into >> an infinite loop when it can't fit something on a page. xmlroff doesn't go >> into an infinite loop anymore; it just happens to not render the problematic >> area at all. > > Tony, > > thanks for all your work. It is very much appreciated ! Wow. I should make disfunctional releases more often. This release is even more than usual a "work in progress" (and as Stefan's next message showed, even more of a work in progress than I had considered it). > Now I should do my part and work, as I promized, on a dictionary for external > graphics. Great. Let me know if you have any questions. Regards, Tony. |
|
From: Tony G. <Ton...@Su...> - 2005-11-02 23:15:11
|
Stefan Seefeld <se...@sy...> writes: > The libfo-compat.xsl file contains a number of typos, which > the attached patch tries to fix. Thanks. I'll commit the change shortly (or you can do it). Regards, Tony. |
|
From: Stefan S. <se...@sy...> - 2005-11-02 20:11:13
|
The libfo-compat.xsl file contains a number of typos, which the attached patch tries to fix. Regards, Stefan |
|
From: Stefan S. <se...@sy...> - 2005-11-02 18:14:58
|
Tony Graham wrote: > xmlroff 0.3.7 is now available from http://sourceforge.net/projects/xmlroff. > > This is a development snapshot, to put it politely, so there's a release "on > or about the first of the month". > > xmlroff 0.3.7 fulfills the letter of Stefan's request that xmlroff not go into > an infinite loop when it can't fit something on a page. xmlroff doesn't go > into an infinite loop anymore; it just happens to not render the problematic > area at all. Tony, thanks for all your work. It is very much appreciated ! Now I should do my part and work, as I promized, on a dictionary for external graphics. Kind regards, Stefan |
|
From: Tony G. <Ton...@Su...> - 2005-11-02 16:30:42
|
xmlroff 0.3.7 is now available from http://sourceforge.net/projects/xmlroff. This is a development snapshot, to put it politely, so there's a release "on or about the first of the month". xmlroff 0.3.7 fulfills the letter of Stefan's request that xmlroff not go into an infinite loop when it can't fit something on a page. xmlroff doesn't go into an infinite loop anymore; it just happens to not render the problematic area at all. Unfortunately, I won't have much time to work on xmlroff until at least the middle of the month, so if there was going to be a monthly release for November, this was the best I can do. When the problem is fixed, there'll be a release that doesn't have to be labelled as a "development snapshot". Regards, Tony. Changes between 0.3.6 and 0.3.7 * Corrected placement of fo:external-graphic if not first on line * Added setting pixels-per-inch (for graphics without intrinsic size) as configure option * Working on averting endless loop if area won't fit on page. Changes: 2005-11-02 Tony Graham <ton...@us...> * === Released 0.3.7 === * NEWS: Updated for 0.3.7. * area/fo-area-viewport-reference.c: Removed unnecessary #includes. * area/fo-area-viewport-reference-private.h: Added a #include. * area/fo-area-page.c: Removed unused variables and #include. * Makefile.am: Added 'srpm' target for making SRPM. * configure.in, libfo/fo-doc-gp.c: Added --disable-clip configure option to turn off clipping in fo-doc-gp.c. 2005-10-11 Tony Graham <ton...@us...> * libfo-compat.xsl: Added changing all keeps below a threshold value to 'auto' since numeric keeps currently not supported. * libfo/fo-doc-gp.c: More futzing with PANGO_SCALE so images appear in right place. 2005-10-02 Tony Graham <ton...@us...> * area/fo-area-page.c: Working on averting endless loop if area won't fit on page. * configure.in, datatype/fo-length.c, libfo/fo-doc-gp.c: Added PIXEL_PER_INCH to configure.in so it appears in config.h. * area/fo-area-list-item.c, area/fo-area-private.h, area/fo-area.c: Started adding split_after_height() and split_after_height_check() functions. * datatype/fo-uri-specification.c: Removed unnecessary statement left over from creating file by copying another file. * libfo/fo-doc-private.h: Removed unnecessary includes. * util/fo-hash-table.c, util/fo-pixbuf.c: Updated doc comments. * area/fo-area-area.c: Reformatted. * area/fo-area-table.c: Renamed some variables to make them easier to read. 2005-09-16 Tony Graham <ton...@us...> * util/Makefile.am, libfo/fo-doc-gp.c, util/fo-image-private.h, util/fo-image.c, util/fo-pixbuf.c, util/fo-pixbuf.h: Added FoPixbuf interface for getting GdkPixbuf from images instead of using fo-image-private.h. * configure.in: Upped version to 0.3.7. * .cvsignore: List of files to ignore when doing 'cvs diff', etc. |
|
From: Tony G. <Ton...@Su...> - 2005-09-13 09:59:28
|
This is something that I keep forgetting how to do that may be of interest to some of you who aren't already doing it: You can monitor xmlroff releases by clicking on any of the envelope symbols in the "Latest File Releases" section of the xmlroff Sourceforge page at http://sourceforge.net/projects/xmlroff/. 14 people are currently monitoring the 'xmlroff' package, so it's of interest to some people. I sometimes think about an xmlroff-announce mailing list since we sometimes lose one or two subscribers when there's a flurry of more than usual traffic on this list, but it seems to me that release monitoring would work just as well. Regards, Tony. |
|
From: Tony G. <Ton...@Su...> - 2005-09-13 09:47:25
|
xmlroff 0.3.6 is now available from https://sourceforge.net/projects/xmlroff News and Changelog are shown below. Thanks go to Gerrit Haase and Stefan Seefeld for submitting improvements. For once the website has been updated by me on the same day as the release was made. Now we just need to notify the XSL-related mailing lists. Any volunteers? Regards, Tony. ------------------------------------------------------------ Changes between 0.3.5 and 0.3.6 * Resolves relative URIs for fo:external-graphic 'src' property values (Stefan Seefeld) * Added 'content-type' to libfo-compat.xsl * Stopped requiring 'content-height' and 'content-width' * Supporting percentages for 'content-height' and 'content-width' * Improved Cygwin support (Gerrit Haase) ------------------------------------------------------------ 2005-09-12 Tony Graham <ton...@us...> * === Released 0.3.6 === * libfo/fo-doc-commands.h, libfo/fo-doc-gp.c, libfo/fo-doc.c: Removed unused fo_doc_open_image_file() and fo_doc_close_image(). * libfo/fo-font-desc.c: Removed unused fo_font_desc_init prototype. * util/fo-image.c: Doc comment change. 2005-09-11 Tony Graham <ton...@us...> * NEWS: Updated for 0.3.6. * result-to-fo.c: Added setting base URI for fo:external-graphic. (Stefan Seefeld) * util/fo-image.c, util/fo-image.h: Changed all 'url' to 'uri'. Added base URI for resolving relative URI values. (Stefan Seefeld) * fo/fo-external-graphic-private.h, fo/fo-external-graphic.c, fo/fo-external-graphic.h: Added 'base-URI' property and new constructor for setting base URI. (Stefan Seefeld) * libfo-compat.xsl: Added removing 'content-type' properties. * datatype/fo-string.c: Cosmetic changes only. 2005-09-09 Tony Graham <ton...@us...> * util/fo-image.c: (fo_image_get_height) Removed creating height instance variable here (as had already been done for width). * util/fo-image.c: Changed to determining width and height when URL is set and unreffing them when FoImage is finalized. * libfo/fo-doc-gp.c, fo/fo-external-graphic-private.h, fo/fo-external-graphic.c: Added scaling image from computed image area width and height. 2005-09-08 Tony Graham <ton...@us...> * util/fo-image.c: Corrected fo_image_get_pixbuf() name. * libfo/fo-doc-gp.c: Changed fo_doc_gp_place_image() to match fo_doc_place_image() changes. Stopped division by PANGO_SCALE that was putting images in wrong places. * fo/fo-external-graphic.c, libfo/fo-doc-commands.h, libfo/fo-doc-private.h, libfo/fo-doc.c: (fo_doc_gp_place_image) Change to use FoImage parameter. Changed from 'scale' parameter to 'xscale' and 'yscale'. * fo/fo-external-graphic-private.h: Added 'xscale' and 'yscale' for passing to fo_doc_place_image(). * fo/fo-multi-switch.h: Corrected filename in initial comment. 2005-09-05 Tony Graham <ton...@us...> * datatype/fo-length.c: Removed parentheses to stop multiplying pixels by zero. * expr/fo-expr-eval.c, datatype/fo-length.c, datatype/fo-length.h: Added fo_length_new_from_pixels(). * fo/fo-external-graphic-private.h, fo/fo-external-graphic.c: Started adding use of FoImage so can implement content-width/height properly. * fo/fo-root.c: Added FO_OBJECT() cast to quieten compiler. * fo/fo-tree.c: Added a g_free(). * property/fo-property-src.c: Removed unused variables. * util/Makefile.am, util/fo-image-private.h, util/fo-image.c, util/fo-image.h: Added FoImage for representing images. * util/fo-hash-table.c: Minor changes to doc comments. 2005-08-23 Tony Graham <ton...@us...> * Makefile.am, configure.in: Added PLATFORM_WIN32 and added all libraries to libfo_0_3_la_LIBADD for cygwin support. (Gerrit Haase) * libfo/fo-layout.c: (fo_layout_fo_rectangle_to_pango_rectangle) Removed unused function. * property/fo-property-font-weight.c: Made enumeration tokens evaluate to integers. * fo/fo-multi-case-private.h, fo/fo-multi-case.c, fo/fo-multi-case.h, fo/fo-multi-toggle-private.h, fo/fo-multi-toggle.c, fo/fo-multi-toggle.h, fo/fo-repeatable-page-master-reference-private.h, fo/fo-repeatable-page-master-reference.c, fo/fo-repeatable-page-master-reference.h: Updated to match latest spec-dump to avoid compiler warnings. 2005-08-18 Tony Graham <ton...@us...> * area/fo-area.h: Added some doc comments. * configure.in: Upped version to 0.3.6. * fo/fo-multi-switch-private.h, fo/fo-multi-switch.c, fo/fo-multi-switch.h: Updated to match latest spec-dump. * xmlroff.fo: Minor text changes. * area/fo-area-layout.c, fo/fo-bidi-override.c, property/fo-property-font-weight.c, property/fo-property-font-weight.h, property/fo-property-text-align.c, property/fo-property-text-align.h, property/fo-property-unicode-bidi.c, property/fo-property-unicode-bidi.h, property/fo-property-width.c, property/fo-property-width.h, property/fo-property-writing-mode.c, property/fo-property-writing-mode.h: Updated to use common FoEnumEnum enums instead of property-specific enums. |
|
From: Tony G. <Ton...@Su...> - 2005-09-12 14:39:33
|
Stefan Seefeld <se...@sy...> writes: > Tony Graham wrote: >> xmlroff 0.3.6 is almost ready, despite Stefan's efforts to remind me of >> essential features. > > I'm sorry, I didn't mean to block a release. Instead, I tried to find spots > where I could help, even with my lack of understanding of the xsl-fo internals. You didn't block a release. I doubt that you've even delayed it. And your contributions are useful. > I do agree that the current handling of the src attribute in external graphic > already covers the majority of all cases, thus greatly enhancing the functionality > of xmlroff. Except the base URI evaporates if you run the input XML through a stylesheet. I still have to think about that one. >> It is, I think, simple and obvious to continue with fo:external-graphic >> improvements for xmlroff 0.3.7. >> The tasks for xmlroff 0.3.7 as I see them are: >> - Support 'http:' (and other) protocols in URI specifications > > I may have a look at that. You would be welcome. >> - Improve handling unresolvable 'src' URI specifications (to be done after >> 'http:' support) > > What do you imagine to happen ? Drop in a fallback graphic ? Do nothing in > the generated document but print out a warning / error ? You obviously haven't tried an unresolvable 'src' URI recently. A comprehensible warning message and avoiding the current numerous failed assertion messages would be a start. I haven't thought much beyond that. >> - Handle more fo:external-graphic properties and handle their >> interdependencies: >> - Handle when one of 'content-width' or 'content-height' is specified > > What is the expected behavior ? To stretch / shrink the image to fit ? If one is non-auto and the other is 'auto', the 'auto' one uses the same scale factor. The spec explains most of it fairly well, except the fo:external-graphic explanation omits mention of the effect of 'scaling-method'. >> - Handle 'scale' attribute >> It would be good to also handle non-auto ipd and bpd and 'display-align' >> and 'text-align' but that will take more effort. >> - Add a FoImageManager or similar so the same image isn't opened multiple >> times > > I may look into that. It should be pretty simple. If should be pretty similar to the hashing in FoColor, except for reasons I can't articulate, I want a separate class for this rather than hiding the existence of the hashing ability. The FoImageManager should also have a 'reset' function that flushes the cache, which would be called at the end of document processing. >> - Handle areas that can't be broken > > Yes, please ! If I can lure you or other people into working on the other pieces with my help, I can work on this. Regards, Tony. |
2 messages has been excluded from this view by a project administrator.
