headers
Altsoft Xml2PDF | 17 Jan 2006 15:15
Favicon

Altsoft Xml2PDF 3.0 Beta released


Altsoft presents the new version 3.0 of its .NET based Xml2PDF formatting
engine. The major new features of the new version include:

- Significant refactoring and optimization which make the new version about
3-4 times faster and 2-3 times less memory consuming than the current
commercial 2.x release;
- The support for raster graphics and GDI output;
- The support for MathML as an external graphics format;
- The support for SVG as an output format;
- The possibility to embed any supported format into any other;
- Improved formatting of all currently supported formats (XSL-FO, SVG,
WordML, XHTML).

All together Xml2PDF 3.0 supports the following file formats:
- Input XML formats: XSL-FO, SVG, XHTML, WordML, MathML.
- Output formats: PDF,SVG, raster graphics (BMP, EMF,TIFF, GIF, JPEG, PNG,
WMF).

The formatting engine is implemented as pure managed .NET components and can
be easily integrated into any .NET-based solution. It does not use any
third-party applications or COM components.

The Xml2PDF 3.0 Beta version does not require any activation keys, but
produces an Altsoft watermark on each page. Please, note that this version
is not recommended for use on any production computer.

The commercial release of Xml2PDF is scheduled for March 2006.

The following three Xml2PDF editions are included into Xml2PDF 3.0 Beta
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grosso, Paul | 18 Jan 2006 20:35

RE: Wording for spaces produces interpretation differences among implementations


The XSL FO SG has discussed this and believes
the wording in the spec is correct rather than
your proposed rephrasing.

Consider a <p> that gets mapped into an fo:block that, 
due to the amount of content, generates two areas on 
two consequtive pages.  We do not want the space before 
the fo:block to occur also on the 2nd page. 

Paul Grosso
for the XSL FO SG

> -----Original Message-----
> From: xsl-editors-request <at> w3.org 
> [mailto:xsl-editors-request <at> w3.org] On Behalf Of Jeremias Maerki
> Sent: Monday, 2005 October 10 4:13
> To: xsl-editors <at> w3.org
> Subject: Wording for spaces produces interpretation 
> differences among implementations
> 
> 
> Dear editors, 
> 
> the Apache FOP team has recently stumbled over a problem 
> concerning the
> interpretation of the space properties. We've documented the 
> problem and
> our interpretation on our Wiki:
> http://wiki.apache.org/xmlgraphics-fop/XslFoSpecificationUncer
(Continue reading)

Permalink | Reply | 501 comments |
headers
Grosso, Paul | 18 Jan 2006 20:35

RE: Proposal: Regions ordering


Thank you for your interest in XSL.

Unfortunately, while the XSL FO SG realizes that it 
would be useful to be able provide a z-order to the
various regions, the SG has decided that this must
be considered outside the scope of the (already
much delayed) XSL 1.1 spec.

We have put the issue of providing z-order to regions
on our list of post-1.1 considerations.  In fact, the
plan is for a future XSL version to have a more complex 
page master FO that should address these and other issues.

Paul Grosso
for the XSL FO SG

________________________________

	From: xsl-editors-request <at> w3.org
[mailto:xsl-editors-request <at> w3.org] On Behalf Of Alexander I Rozhenko
	Sent: Saturday, 2005 September 10 3:44
	To: xsl-editors <at> w3.org
	Subject: Proposal: Regions ordering
	
	
	Hello XSL Editors,
	 
	The XSL FO Specifications 1.0 and 1.1 do not specify an order
regions are placed on a page. The order of regions is quite important
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grosso, Paul | 18 Jan 2006 20:37

RE: Proposal: Regions with auto-extent


Thank you for your interest in XSL.

The XSL FO SG notes that this enhancement request 
is outside the scope of the XSL 1.1 spec.

The plan is for a future XSL version to have a more complex 
page master FO that should address these and other issues.

Paul Grosso
for the XSL FO SG 

________________________________

	From: xsl-editors-request <at> w3.org
[mailto:xsl-editors-request <at> w3.org] On Behalf Of Alexander I Rozhenko
	Sent: Saturday, 2005 September 10 5:16
	To: xsl-editors <at> w3.org
	Subject: Proposal: Regions with auto-extent
	
	
	Hello Editiors,
	 
	This is another proposal that allows automatically adjust a body
region if static-content regions overlap it. This issue is concerned
with adjustment aka MS Word.
	 
	In MS Word, the extent of headers and footers is not specified.
When a header/footer goes over the text area, the top/bottom margin of
the text area is adjusted to avoid overlapping. Many users of RTF2FO
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grosso, Paul | 18 Jan 2006 20:57

RE: 1.1 WD suggestions on extension attributes/properties


Regarding your item 1, the current wording is
meant to imply that extension properties may
only change the behavior of an FO in ways that 
are beyond what the spec says for a particular 
FO.  Some examples of permitted extensions might
be like specifying a hyphenation dictionary or 
hyphenation exception, specifying a whitespace
distribution algorithm, etc.

While the XSL FO SG was somewhat divided on
the issue, and we certainly do appreciate the
viewpoint you espouse, on the whole we have
decided to stick with the more restrictive 
intension currently in the spec.  We feel that 
allowing for extensions that substantially change 
the already defined semantics for a given FO will 
cause too many implementation issues.

We are planning to clarify the spec be including 
something like:

 This means that an extension attribute must not 
 change the processing of any FO in such a way that
 the constraints specified by XSL on that FO are
 no longer satisfied.

On your item 2, we agree.  We will make the
change you suggest.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grosso, Paul | 18 Jan 2006 20:56

RE: line-stacking-strategy line-height


> ...for inline areas returning the normal-allocation-rectangle 
> which have border and/or padding[,] the before-/afer-edges of 
> the expanded rectangle would 'cut through' the border/padding 
> areas. 

Yes, that was the intention. The intended effect is that 
adding a border or background will not alter the line spacing.

> ... Was that the intention or is the half-leading to be
> added to the height of the content rectangle and any
> borders/padding therefore to be outside of that?

No, that was not the intent. The half-leading is used in 
determining the line-spacing, but does not alter the 
allocation area of the inline object itself.

These 2 decisions allow borders and/or backgrounds to be 
used as a way to highlight inline text where lines need 
to line up, such as in parallel columns. 

If the line spacing is fairly tight or the border+padding 
on a given inline object is fairly large, the border and 
background can intrude into the line-area above or the 
line-area below the current line-area (hence, yes, the 
line-area's before/after edge can cut through the child 
inline's padding and border areas).

Note that the line area has no border or padding, only the 
inlines within the line can have have padding and borders.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grosso, Paul | 18 Jan 2006 21:07

RE: Overconstraint alignment


Thank you for your input here.

Since this issue exists in XSL 1.0, and the SG is
busy trying to get out a Candidate Recommendation
for XSL 1.1, we plan to handle this as a potential
erratum to XSL 1.0 (which, if requiring a change
to the spec, will be rolled into the XSL 1.1 spec
before it becomes a Recommendation).

What that means in practice is that we won't let
this issue hold up our plan to take XSL 1.1 to
CR in the near future, but we will consider this
issue as soon as possible thereafter.

Paul Grosso
for the XSL FO SG

> -----Original Message-----
> From: xsl-editors-request <at> w3.org 
> [mailto:xsl-editors-request <at> w3.org] On Behalf Of Manuel Mall
> Sent: Friday, 2005 October 21 1:41
> To: xsl-editors <at> w3.org
> Subject: Overconstraint alignment
> 
> 
> Dear Editors,
> 
> With respect to line areas there can be conflicting or overconstraint
> alignment specifications. I couldn't find a reference to that
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grosso, Paul | 18 Jan 2006 21:05

RE: allowed-height-scale/allowed-width-scale value


Thank you for pointing out the typo; we will fix that.

The XSL FO SG has decided to leave the content model
as is and assume that implementations will do 
reasonable things with potentially aberrant values.

Paul Grosso
for the XSL FO SG 

> -----Original Message-----
> From: xsl-editors-request <at> w3.org 
> [mailto:xsl-editors-request <at> w3.org] On Behalf Of Alexander Peshkov
> Sent: Tuesday, 2005 November 01 6:16
> To: xsl-editors <at> w3.org
> Subject: allowed-height-scale/allowed-width-scale value
> 
> 
> Dear Editors,
> 
> I believe that I've found a minor mistype in the value description
> used for allowed-height-scale/allowed-width-scale properties:
> 
>     [ any | <percentage;> ]* | inherit
> 
> the semicolon after "percentage" shouldn't be there (there is no
> basic data type "percentage;").
> The same mistype present in the description of "intrinsic-scale-value"
> property.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grosso, Paul | 18 Jan 2006 21:07

RE: alignment-baseline values before-/after-edge


Thank you for your input here.

Since this issue exists in XSL 1.0, and the SG is
busy trying to get out a Candidate Recommendation
for XSL 1.1, we plan to handle this as a potential
erratum to XSL 1.0 (which, if requiring a change
to the spec, will be rolled into the XSL 1.1 spec
before it becomes a Recommendation).

What that means in practice is that we won't let
this issue hold up our plan to take XSL 1.1 to
CR in the near future, but we will consider this
issue as soon as possible thereafter.

Paul Grosso
for the XSL FO SG 

> -----Original Message-----
> From: xsl-editors-request <at> w3.org 
> [mailto:xsl-editors-request <at> w3.org] On Behalf Of Manuel Mall
> Sent: Friday, 2005 October 21 1:25
> To: xsl-editors <at> w3.org
> Subject: alignment-baseline values before-/after-edge
> 
> 
> Dear Editors,
> 
> In 
> http://lists.w3.org/Archives/Public/xsl-editors/2005OctDec/000
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grosso, Paul | 18 Jan 2006 21:07

RE: inline-containers and before-/after-edge baselines


Thank you for your input here.

Since this issue exists in XSL 1.0, and the SG is
busy trying to get out a Candidate Recommendation
for XSL 1.1, we plan to handle this as a potential
erratum to XSL 1.0 (which, if requiring a change
to the spec, will be rolled into the XSL 1.1 spec
before it becomes a Recommendation).

What that means in practice is that we won't let
this issue hold up our plan to take XSL 1.1 to
CR in the near future, but we will consider this
issue as soon as possible thereafter.

Paul Grosso
for the XSL FO SG 

> -----Original Message-----
> From: xsl-editors-request <at> w3.org 
> [mailto:xsl-editors-request <at> w3.org] On Behalf Of Manuel Mall
> Sent: Friday, 2005 October 21 1:34
> To: xsl-editors <at> w3.org
> Subject: inline-containers and before-/after-edge baselines
> 
> 
> Dear Editors,
> 
> According to section 7.13 (7.14 in the draft) the "before-edge" and
> after-edge" baselines are only defined for
(Continue reading)

Permalink | Reply | 0 comments |

Gmane