xmlroff-list — xmlroff XSL formatter discussion list

Re: [xmlroff] Re: xmlroff on Windows

[Tony G. <Ton...@Su...>]

Jesper Stigberg wrote at  8 May 2003 14:39:29 +0200:
 > Tony Graham wrote:
...
 > > I have started a Wiki page to collect in one place all the possibly
 > > differing interpretations of device units from XSL, Pango, and
 > > FreeType (although I haven't got to FreeType yet).  You are welcome to
 > > annotate it.
 > 
 > Great. What do gnome-print use as a unit?

So far I've found that the PDF and PostScript outputs use different
units.  GNOME Print is under-documented, so there may be something
that I'm missing.

See pangogp-to-pdf.c in pangopdf/examples.

 > > What do you do in your rendering application if you want to scale the
 > > rendered image, e.g. reduce it so a whole page appears in the window?
 > > 
 > 
 > A bit simplified.
 > 
 > In the win32 GDI (graphics device interface), all drawing,
 > text-output etc is done through a device-context using
 > logical-units. What appears on the screen is measured in
 > device-units. A device-unit==scale*logical-unit ( this mapping is
 > done by the OS ). So by changing the scale you can get a zoom
 > effect without changing the coordinates etc in your drawing code,
 > or use the same code to render to a printer.

And the logical unit is a 'twip', i.e., a logical pixel?

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

Re: [xmlroff] Re: xmlroff on Windows

[Jesper S. <je...@no...>]

Tony Graham wrote:
> Jesper Stigberg wrote at 30 Apr 2003 14:01:55 +0200:
>  > Tony Graham wrote:
> But a device unit is a point for font sizes:
> 
>    There are PANGO_SCALE Pango units in one device unit (device unit
>    is a point, for font sizes).
> 
> (See http://developer.gnome.org/doc/API/2.0/pango/pango-Fonts.html#pango-font-description-set-size)

Yes.

> ..
>  > If the pango version in use uses pt as 'device-unit', all is
>  > fine. But if it uses another unit we have a mix of units.
> 
> Which is why so far it has been fine, and why it creates problems for
> your screen rendering backend.
> 

Yup.

> I have started a Wiki page to collect in one place all the possibly
> differing interpretations of device units from XSL, Pango, and
> FreeType (although I haven't got to FreeType yet).  You are welcome to
> annotate it.

Great. What do gnome-print use as a unit?

> What do you do in your rendering application if you want to scale the
> rendered image, e.g. reduce it so a whole page appears in the window?
> 

A bit simplified.

In the win32 GDI (graphics device interface), all drawing, text-output etc is 
done through a device-context using logical-units. What appears on the screen is 
measured in device-units. A device-unit==scale*logical-unit ( this mapping is 
done by the OS ). So by changing the scale you can get a zoom effect without 
changing the coordinates etc in your drawing code, or use the same code to 
render to a printer.

> ..
>  > > Also, the XSL Recommendation errata says that 1 px = 1/96 inch.
> 
> Actually, it's a CSS2 erratum
> (http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html),
> and the XSL 1.0 erratum removes the size recommendation from the XSL
> 1.0 Recommendation (so XSL won't be bothered by any future dpi changes
> in CSS).
> 
>  > Note that in fo-expr-eval.c pt==px.
>  > 
>  > #define POINT2DEVICE(x)		x
>  > #define PIXEL2DEVICE(x)		x
>  > 
>  > Do you want me to file a bug?
> 
> Sure.  Note also that the code for fo:external-graphic has wavered
> about the dpi.

Noted.

Regards,
Jesper.

[xmlroff] New xmlroff Wiki pages

[Tony G. <Ton...@Su...>]

I have recently added pages on:

 - Relating xmlroff units to Pango units

 - Using GNOME Print (pangogp) with xmlroff

 - Anatomy of a fo-*-area.c file

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

Re: [xmlroff] Re: xmlroff on Windows

[Tony G. <Ton...@Su...>]

Jesper Stigberg wrote at 30 Apr 2003 14:01:55 +0200:
 > Tony Graham wrote:
...
 > I think that this is the problem. From:
 > http://developer.gnome.org/doc/API/2.0/pango/pango-Glyph-Storage.html#PangoGlyphUnit
 > 
 > "...The PangoGlyphUnit type is used to store dimensions within
 > Pango. Dimensions are stored in 1/PANGO_SCALE of a device unit. (A
 > device unit might be a pixel for screen display, or a point on a
 > printer.)..."
 > 
 > note the "...(A device unit might be a pixel for screen display, or
 > a point on a printer.)..." i.e. a 'device-unit' may be a pt, but it
 > does not have to.

But a device unit is a point for font sizes:

   There are PANGO_SCALE Pango units in one device unit (device unit
   is a point, for font sizes).

(See http://developer.gnome.org/doc/API/2.0/pango/pango-Fonts.html#pango-font-description-set-size)

...
 > If the pango version in use uses pt as 'device-unit', all is
 > fine. But if it uses another unit we have a mix of units.

Which is why so far it has been fine, and why it creates problems for
your screen rendering backend.

I have started a Wiki page to collect in one place all the possibly
differing interpretations of device units from XSL, Pango, and
FreeType (although I haven't got to FreeType yet).  You are welcome to
annotate it.

What do you do in your rendering application if you want to scale the
rendered image, e.g. reduce it so a whole page appears in the window?

...
 > > Also, the XSL Recommendation errata says that 1 px = 1/96 inch.

Actually, it's a CSS2 erratum
(http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html),
and the XSL 1.0 erratum removes the size recommendation from the XSL
1.0 Recommendation (so XSL won't be bothered by any future dpi changes
in CSS).

 > Note that in fo-expr-eval.c pt==px.
 > 
 > #define POINT2DEVICE(x)		x
 > #define PIXEL2DEVICE(x)		x
 > 
 > Do you want me to file a bug?

Sure.  Note also that the code for fo:external-graphic has wavered
about the dpi.

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

Re: [xmlroff] Re: xmlroff on Windows

[Jesper S. <je...@no...>]

Tony Graham wrote:

....

>  > 
>  > *** If I understand xmlroff correctly you are using pt as 'device-unit'. This 
>  > works ok when using pangopdflib since it too (I assume) use pt as
>  > unit, but my pango-win32 backend use pixel as unit. The result of
>  > this is that all lengths/widths/heights are sometimes measured in
>  > pixel (when they are 'received' from pango) and sometimes in
>  > pt. It's not possible to know when to convert from pt to px and
>  > when not to do it.
> 
> Yes, xmlroff uses pt as the 'device-unit'; i.e., it converts all
> dimensions in the FO expressions into points.
> 
> I haven't looked at the Pango Win32 backend, but Pango uses 1/1024 pt
> as a 'Pango Unit', and defines PANGO_SCALE to simplify converting
> points to Pango units.  

I think that this is the problem. From:
http://developer.gnome.org/doc/API/2.0/pango/pango-Glyph-Storage.html#PangoGlyphUnit

"...The PangoGlyphUnit type is used to store dimensions within Pango. Dimensions 
are stored in 1/PANGO_SCALE of a device unit. (A device unit might be a pixel 
for screen display, or a point on a printer.)..."

note the "...(A device unit might be a pixel for screen display, or a point on a 
printer.)..." i.e. a 'device-unit' may be a pt, but it does not have to.

>Pango uses Pango units except when it doesn't;
> e.g. for font sizes.  Unfortunately, the Pango functions just use
> 'int' for all dimensions rather than defining a type for Pango units.
> (Actually, PangoGlyphUnit is defined in pango-glyph.h but is mostly
> only used in doc comments.)
> 
>  > I can see two solutions to this:
>  > 
>  > 1. All pango-backends compatible with xmlroff must use pt as a unit.
>  > 
>  > 2. Use a 'scale' in xmlroff to convert to pango-device-units, or convert from 
>  > pango-device-units to xmlroff-device-units.
> 
> Or:
> 
> 3. Require the child types of FoDoc (wish I had a better name for it)
>    to handle the conversion from points (i.e., xmlroff units) to
>    Pango backend units.

I don't think this will work. Consider this snippet from fo-block-area.c:

void
fo_block_area_new(...)
{

   ...

   pango_layout_get_extents (pango_layout, NULL, &logical);

   fo_area_area_set_height (*new_area,
			   logical.height / PANGO_SCALE +
			   border_before_width + padding_before +
			   border_after_width + padding_after);
   ...

}

If the pango version in use uses pt as 'device-unit', all is fine. But if it 
uses another unit we have a mix of units.


>    For example, the current fo_doc_pdflib_render_layout() code does
>    the multiplication by PANGO_SCALE to convert xmlroff units to Pango
>    units.
> 
>    And, having complained about Pango, it now seems that xmlroff
>    should define and use a typedef for xmlroff units to save people
>    from repeating your confusion.
> 
>  > 1. will loose precision and will not be compatible with:
>  > http://developer.gnome.org/doc/API/2.0/pango/pango-Glyph-Storage.html#PangoGlyphUnit
>  > 
>  > 2. seems the way to do it. I don't know if there is an API in pango that lets 
>  > you express the device-unit in a 'known' unit, i.e. 'pango_deviceunit_to_twips' 
>  > etc. If not, the 'scale' has to be set explicit by the 'client' of xmlroff/libfo.
> 
> In theory, the FT2 backend requires you to specify the resolution when
> creating a PangoContext (or a PangoFT2Context), but the call to
> FT_Set_Char_Size() in pangoft2.c shows that the resolution isn't
> really used.
> 
> Also, the XSL Recommendation errata says that 1 px = 1/96 inch.

Note that in fo-expr-eval.c pt==px.

#define POINT2DEVICE(x)		x
#define PIXEL2DEVICE(x)		x

Do you want me to file a bug?

Regards,
Jesper.

Re: [xmlroff] Re: xmlroff on Windows

[Tony G. <Ton...@Su...>]

Tony Graham wrote at 29 Apr 2003 17:48:39 +0100:
 > Jesper Stigberg wrote at 25 Apr 2003 16:50:25 +0200:
 >  > Sorry for the late reply.
...
 >  > Tony Graham wrote:
...
 >  > > Now that none of area-to-pdf uses PDFlib, it is also possible to break
 >  > > up area-to-pdf and put each area type's code into the area type's
 >  > > implementation of the currently unused 'draw' function of FoArea.
 >  > 
 >  > Is this something you are planning todo in the nearest future?
 > 
 > It's actually something that I've wanted to do for a long time but haven't

I meant to say that I intend to write the pangogp version of FoDoc
first.

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

Re: [xmlroff] Re: xmlroff on Windows

[Tony G. <Ton...@Su...>]

Jesper Stigberg wrote at 25 Apr 2003 16:50:25 +0200:
 > Sorry for the late reply.

That's okay.  I've only just got back from the second half of my
vacation.

 > Tony Graham wrote:
 > > Are you able to contribute your code to xmlroff or PangoPDF?
 > > 
 > 
 > Yes, as soon as I have some more time and the code is in reasonable shape I will.

Great.

 > Perhaps the best thing would be to write the 'screen renderer' in a cross 
 > platform tool kit (wxWindows,QT,GTK+) and use a pango backend based on
 > FT2/fontconfig.

There is a QT example in the core Pango examples that may be useful to
you.

...
 > > Now that none of area-to-pdf uses PDFlib, it is also possible to break
 > > up area-to-pdf and put each area type's code into the area type's
 > > implementation of the currently unused 'draw' function of FoArea.
 > 
 > Is this something you are planning todo in the nearest future?

It's actually something that I've wanted to do for a long time but haven't

 > And now ower to something completely different.
 > 
 > *** If I understand xmlroff correctly you are using pt as 'device-unit'. This 
 > works ok when using pangopdflib since it too (I assume) use pt as
 > unit, but my pango-win32 backend use pixel as unit. The result of
 > this is that all lengths/widths/heights are sometimes measured in
 > pixel (when they are 'received' from pango) and sometimes in
 > pt. It's not possible to know when to convert from pt to px and
 > when not to do it.

Yes, xmlroff uses pt as the 'device-unit'; i.e., it converts all
dimensions in the FO expressions into points.

I haven't looked at the Pango Win32 backend, but Pango uses 1/1024 pt
as a 'Pango Unit', and defines PANGO_SCALE to simplify converting
points to Pango units.  Pango uses Pango units except when it doesn't;
e.g. for font sizes.  Unfortunately, the Pango functions just use
'int' for all dimensions rather than defining a type for Pango units.
(Actually, PangoGlyphUnit is defined in pango-glyph.h but is mostly
only used in doc comments.)

 > I can see two solutions to this:
 > 
 > 1. All pango-backends compatible with xmlroff must use pt as a unit.
 > 
 > 2. Use a 'scale' in xmlroff to convert to pango-device-units, or convert from 
 > pango-device-units to xmlroff-device-units.

Or:

3. Require the child types of FoDoc (wish I had a better name for it)
   to handle the conversion from points (i.e., xmlroff units) to
   Pango backend units.

   For example, the current fo_doc_pdflib_render_layout() code does
   the multiplication by PANGO_SCALE to convert xmlroff units to Pango
   units.

   And, having complained about Pango, it now seems that xmlroff
   should define and use a typedef for xmlroff units to save people
   from repeating your confusion.

 > 1. will loose precision and will not be compatible with:
 > http://developer.gnome.org/doc/API/2.0/pango/pango-Glyph-Storage.html#PangoGlyphUnit
 > 
 > 2. seems the way to do it. I don't know if there is an API in pango that lets 
 > you express the device-unit in a 'known' unit, i.e. 'pango_deviceunit_to_twips' 
 > etc. If not, the 'scale' has to be set explicit by the 'client' of xmlroff/libfo.

In theory, the FT2 backend requires you to specify the resolution when
creating a PangoContext (or a PangoFT2Context), but the call to
FT_Set_Char_Size() in pangoft2.c shows that the resolution isn't
really used.

Also, the XSL Recommendation errata says that 1 px = 1/96 inch.

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

Re: [xmlroff] Re: xmlroff on Windows

[Jesper S. <je...@no...>]

Tony, All,

Sorry for the late reply.

Tony Graham wrote:
> 
> Are you able to contribute your code to xmlroff or PangoPDF?
> 

Yes, as soon as I have some more time and the code is in reasonable shape I will.
Perhaps the best thing would be to write the 'screen renderer' in a cross 
platform tool kit (wxWindows,QT,GTK+) and use a pango backend based on
FT2/fontconfig.

>  > I also had to change area-to-pdf, since it used PDFLib, but I don't
>  > think that it would be to hard to avoid that. If that happens
>  > perhaps area-to-pdf could be renamed to something like
>  > render-area.[hc]?
> 
> The current CVS code has fo_doc_render_layout() and
> fo_doc_render_layout_lines() so area-to-pdf no longer has any
> dependency on PDFlib.

Time to sync with cvs. Greate!

> 
> area-to-pdf is called that because it described what was happening at
> the time.
> 
> Now that none of area-to-pdf uses PDFlib, it is also possible to break
> up area-to-pdf and put each area type's code into the area type's
> implementation of the currently unused 'draw' function of FoArea.
> 

Is this something you are planning todo in the nearest future?

And now ower to something completely different.

*** If I understand xmlroff correctly you are using pt as 'device-unit'. This 
works ok when using pangopdflib since it too (I assume) use pt as unit, but my 
pango-win32 backend use pixel as unit. The result of this is that all 
lengths/widths/heights are sometimes measured in pixel (when they are 'received' 
from pango) and sometimes in pt. It's not possible to know when to convert from 
pt to px and when not to do it.

I can see two solutions to this:

1. All pango-backends compatible with xmlroff must use pt as a unit.

2. Use a 'scale' in xmlroff to convert to pango-device-units, or convert from 
pango-device-units to xmlroff-device-units.


1. will loose precision and will not be compatible with:
http://developer.gnome.org/doc/API/2.0/pango/pango-Glyph-Storage.html#PangoGlyphUnit

2. seems the way to do it. I don't know if there is an API in pango that lets 
you express the device-unit in a 'known' unit, i.e. 'pango_deviceunit_to_twips' 
etc. If not, the 'scale' has to be set explicit by the 'client' of xmlroff/libfo.

Thoughts?

Have a nice weekend,
Jesper.

*** May contain traces of nuts.

Re: [xmlroff] Re: xmlroff on Windows

[Tony G. <Ton...@Su...>]

Jesper Stigberg wrote at 16 Apr 2003 14:43:23 +0200:
 > I have both a new implementation of FoDoc and a new pango backend.
 > 
 > The reasons for the new pango version are:
 > 
 > * had to incorporate your xsl-attributes and layout changes
 > * pango-win32 assumed a coordinate system where (0,0) is in the upper left 
 > corner growing down for increasing Y, xmlroff/PDFLib uses the lower left corner 
 > for (0,0).

I understand.

Are you able to contribute your code to xmlroff or PangoPDF?

 > I also had to change area-to-pdf, since it used PDFLib, but I don't
 > think that it would be to hard to avoid that. If that happens
 > perhaps area-to-pdf could be renamed to something like
 > render-area.[hc]?

The current CVS code has fo_doc_render_layout() and
fo_doc_render_layout_lines() so area-to-pdf no longer has any
dependency on PDFlib.

area-to-pdf is called that because it described what was happening at
the time.

Now that none of area-to-pdf uses PDFlib, it is also possible to break
up area-to-pdf and put each area type's code into the area type's
implementation of the currently unused 'draw' function of FoArea.

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

Re: [xmlroff] Re: xmlroff on Windows

[Jesper S. <je...@no...>]

Tony Graham wrote:
> 
> So you have both a new FoDoc variant and a new Pango backend variant?
> Or just a FoDoc variant for the Win32 backend of Pango?
> 
I have both a new implementation of FoDoc and a new pango backend.

The reasons for the new pango version are:

* had to incorporate your xsl-attributes and layout changes
* pango-win32 assumed a coordinate system where (0,0) is in the upper left 
corner growing down for increasing Y, xmlroff/PDFLib uses the lower left corner 
for (0,0).

I also had to change area-to-pdf, since it used PDFLib, but I don't think that 
it would be to hard to avoid that. If that happens perhaps area-to-pdf could be 
renamed to something like render-area.[hc]?

Regards,
Jesper

[xmlroff] Re: xmlroff on Windows

[Tony G. <Ton...@Su...>]

Jesper Stigberg wrote at 15 Apr 2003 22:41:01 +0200:
 > Tony Graham wrote:
...
 > > As an aside, I'm pleased that pangogp can render Thai and Arabic,
 > > which pangopdflib can't.
 > 
 > Because of PDFLib?

Yes. Thai and Arabic have context-dependent glyphs.  The GNOME Print
backend uses GNOME Print glyphlists, so there's no problem.  The
PDFlib backend has to map glyphs back to glyph names in the Adobe
Glyph List (AGL) (and not the current AGL version, at that).  When a
font doesn't use a glyph name from the supported AGL version, PDFlib
can't cope.

 > >  On the downside, pangogp can't do CJK, which
 > > pangopdflib can (if you only use the standard Adobe fonts).  Can your
 > > Win32 screen renderer handle non-Roman scripts?
 > 
 > I haven't tried yet, but I don't think there should be any problems thats not 
 > solvable.

That's good.  I've since found problems with both my Arabic and Thai
implementations.

I'm using the pangoft2topgm program from the Pango examples directory
and lines from HELLO.utf8 as my benchmark for script support.

...
 > > Where do you also need to add fo_doc_begin_path/fo_doc_end_path in
 > > area-to-pdf.c?
 > > 
 > 
 > Surounding the 'function calls'/figures that should be part of the path
 > 
 > fo_doc_begin_path(...);
 > ....
 > fo_doc_move_to(...);
 > fo_doc_line_to(...);
 > ....
 > fo_doc_end_path(...);
 > 
 > fo_doc_fill_stroke(...);
 > 
 > or did I misunderstand you?

That is what I asked, thank you.

 > To be frank, I have just implemented fo_doc_{begin,end}_page,
 > fo_doc_translate, fo_doc_move_to etc and concentrated on pango to
 > see if I can get the text layout correctly (well, I did
 > fo_doc_line_to for debugging), so I haven't really given it enough
 > thought (will post a suggestion/patch when I have).

So you have both a new FoDoc variant and a new Pango backend variant?
Or just a FoDoc variant for the Win32 backend of Pango?

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

[xmlroff] Re: xmlroff on Windows

[Tony G. <Ton...@Su...>]

Jesper Stigberg and I started out by discussing his Windows port of
xmlroff, but the discussion is now more general, so we're moving it
here.

Jesper Stigberg wrote at 15 Apr 2003 22:41:01 +0200:
 > Tony Graham wrote:
 > > Jesper,
 > > 
 > > Can we move this exchange to pangopdf-list or xmlroff-list?
 > 
 > Yes, please forward this to one of the lists if you think there is enough 
 > context/background.
 > 
 > > 
 > > Jesper Stigberg wrote at 14 Apr 2003 13:40:35 +0200:
 > >  > Tony Graham wrote:
 > >  > > I've added pango-xsl-attributes.[ch] to CVS so some includes of
 > >  > > pangopdflib.h have changed to including pango-xsl-attributes.h.
 > >  > 
 > >  > Excelent news. One question: Do we really need separete
 > >  > pangopdflib-layout.[hc], pangogp-layout.[hc] etc? Couln't we manage
 > >  > with pango-xsl-layout.[hc]?  I havn't looked at pangogp-layout.[hc]
 > >  > but I would belive that the algorithms for keeps/breaks etc are the
 > >  > same for the different implementations.
 > > 
 > > I also wish that we didn't need separate
 > > pango{pdflib,gp}-{layout,fontmap}.[ch], etc., but doing so seems the
 > > current 'Pango Way'.
 > > 
 > > pangopdflib*.[ch] borrowed heavily from pangoft2*.[ch], and
 > > pangogp*.[ch] is little more than a search-and-replace on
 > > pangopdflib*.[ch] with a bit of a rewrite of the pango_gp_render*()
 > > functions.
 > > 
 > > It would be simpler if there was a parent type of PangoGPLayout,
 > > PangoPDFLIBLayout, and PangoFT2Layout that handled the common code.
 > > 
 > >  > What I'm trying to say is that instead of libpango.[so|dll] and
 > >  > libpangopdflib.[so|dll] or libpangogp.[so|dll] we could have
 > >  > libpango.[so|dll] ( with no xsl specific code) libpangoxsl[so.dll]
 > >  > (with the general/common xsl stuff ) and libpangogp.[so|dll] (
 > >  > which handles rendering, fonts etc )
 > > 
 > > One thing that should be done in the base Pango code is to make all
 > > the stuff in pangofc-fontmap.cI into a GObject class that is a child
 > > type of PangoFontMap.  PangoGPFontMap, PangoFT2FontMap, and
 > > PangoPDFLIBFontMap could then be child types of that type and save a
 > > lot of duplicate code.  I haven't done it in PangoPDF because it would
 > > complicate updating PangoPDF when the base Pango changes.
 > > 
 > > There was something that I thought of doing when I added
 > > fo-pango-context.[ch] to xmlroff that would greatly reduce the
 > > dependence of xmlroff modules on Pango headers, but I didn't do it
 > > then because it would be a lot of work, but now I've forgotten the
 > > details of what I wanted to do.  It should come back to me while I'm
 > > tinkering with xmlroff to add pangogp support.
 > > 
 > > I am hoping that FoPangoContext can separate xmlroff from most of the
 > > details of Pango backends.  That's also part of why the pangogp
 > > render() functions take a PangoContext and not a GnomePrintContext,
 > > but that really only works because the GNOME Print backend only works
 > > on one GnomePrintContext at a time, whereas the FT2 or xft backend
 > > could be expected to render to multiple bitmaps associated with one
 > > PangoContext.
 > > 
 > > As an aside, I'm pleased that pangogp can render Thai and Arabic,
 > > which pangopdflib can't.
 > 
 > Because of PDFLib?
 > 
 > >  On the downside, pangogp can't do CJK, which
 > > pangopdflib can (if you only use the standard Adobe fonts).  Can your
 > > Win32 screen renderer handle non-Roman scripts?
 > 
 > I haven't tried yet, but I don't think there should be any problems thats not 
 > solvable.
 > 
 > > 
 > >  > > Are you working from the CVS version of xmlroff or the released
 > >  > > version?
 > >  > 
 > >  > For xmlroff I did the last cvs update about a week ago. For pango,
 > >  > I have used one of the first of your releases.
 > > 
 > > I'm glad that you're using the CVS version.
 > > 
 > > xmlroff changed today, for the first time in about two weeks, because
 > > of pango-xsl-attributes.[ch].
 > > 
 > >  > FYI, I did some hacking on the win32 'screen-render' ( I really don't know what 
 > >  > to call it ) during the weekend and can know render xmlroff.fo reasonably ok ( 
 > >  > there are some problems with line height/spacing and font sizes ).
 > >  > 
 > >  > About FoDoc, in win32 you have to explicit begin/end a path before
 > >  > you strike/fill it but in PDFLib it seems that a path is implicit
 > >  > begun/ended, so maybe there could be a
 > >  > fo_doc_begin_path/fo_doc_end_path function in FoDoc, which is not
 > >  > implemented for FoDocPDFLIB. I don't know how GNOME print behaves
 > >  > in respect to this. I realise that win32 isn't a primary platform
 > >  > fo you so this is just a suggestion.
 > > 
 > > Win32 is not a primary platform for me, but Win32 support would
 > > greatly add to the appeal of xmlroff, so I do want to support it.
 > > 
 > > Where do you also need to add fo_doc_begin_path/fo_doc_end_path in
 > > area-to-pdf.c?
 > > 
 > 
 > Surounding the 'function calls'/figures that should be part of the path
 > 
 > fo_doc_begin_path(...);
 > ....
 > fo_doc_move_to(...);
 > fo_doc_line_to(...);
 > ....
 > fo_doc_end_path(...);
 > 
 > fo_doc_fill_stroke(...);
 > 
 > or did I misunderstand you?
 > 
 > To be frank, I have just implemented fo_doc_{begin,end}_page, fo_doc_translate, 
 > fo_doc_move_to etc and concentrated on pango to see if I can get the text layout 
 > correctly (well, I did fo_doc_line_to for debugging), so I haven't really given 
 > it enough thought (will post a suggestion/patch when I have).
 > 
 > > I also need to see what GNOME Print requires for beginning and ending
 > > paths, and it may well require explicit begin and end calls.
 > > 
 > >  > Is there a document somewere describing the units used, coordinat
 > >  > systems and other details of xmlroff?
 > > 
 > > The XSL Recommendation?
 > > 
 > > Ask your questions on the xmlroff-list or on the Wiki and I will do my
 > > best to answer them.
 > 
 > Will do.
 > 
 > Regards,
 > Jesper
 > 
 > 

Re: [xmlroff] Initial pangogp (GNOME Print) backend

[Tony G. <Ton...@Su...>]

Dave Malcolm wrote at 11 Apr 2003 18:35:19 +0100:
 > (i) Am I right in thinking that this lets you render a PangoLayout to a 
 > GnomePrintContext, and, in theory, wouldn't require PDFLib? (avoids 
 > dependencies, and licensing issues)

Correct.  There is no PDFlib dependency in the pangogp backend.

 > (ii) Am I right in thinking that the next stage is to have xmlroff
 > implement GnomePrint as a FoDoc backend and that this isn't yet
 > implemented?

Correct, including the fact that this is not implemented yet.

There's more to it than just implementing a GNOME Print child type of
the existing FoDoc since, for example, PDFlib and GNOME Print have
different ways of handling graphics so presumably FoDoc has to provide
functions for handling graphics.

There's also the question that I put on the PangoPDF Wiki about
whether the GNOME Print glyphlist for a layout should be part of the
PangoContext (actually, PangoGPContext) or a parameter to
pango_gp_render(), etc.  Right now, pangogp avoids the issue by making
a separate glphlist for each run, which is not very efficient.

Also, there's a lot of '#include <pango/pangopdflib.h>' in the xmlroff
code that needs to be worked around.

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

Re: [xmlroff] Initial pangogp (GNOME Print) backend

[Dave M. <da...@da...>]

On Wednesday 09 April 2003 03:54, Tony Graham wrote:
> I have checked in an initial pass at a GNOME Print backend for
> PangoPDF.  See the CVS link at http://pangopdf.sourceforge.net/.
>
> At this point, the pangogp-to-pdf program in the examples directory
> produces a PDF file.

Thanks - please keep working at this!  Being able to print FO documents using 
GnomePrint will be very useful for the free XML editor I'm working on 
(www.conglomerate.org).  Sorry I can't contribute directly.

Have just had a quick browse through the code.  I have two questions:

(i) Am I right in thinking that this lets you render a PangoLayout to a 
GnomePrintContext, and, in theory, wouldn't require PDFLib? (avoids 
dependencies, and licensing issues)

(ii) Am I right in thinking that the next stage is to have xmlroff implement 
GnomePrint as a FoDoc backend and that this isn't yet implemented?

Thanks (am stuck behind a _really_ slow internet connection so there's a 
limit to what I can download)

Dave Malcolm

[xmlroff] ANN: PangoPDF 1.2.1.1

[Tony G. <Ton...@Su...>]

PangoPDF 1.2.1.1 is now available at
http://sourceforge.net/projects/pangopdf/.

Overview of Changes in Pango 1.2.1.1
====================================

* Added GNOME Print (pangogp) backend.
* Updated FT2, X, and xft backends to match Pango 1.2.1.

The new pangogp-to-pdf program in the examples directory actually
produces either PDF or PostScript output.

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

[xmlroff] Initial pangogp (GNOME Print) backend

[Tony G. <Ton...@Su...>]

I have checked in an initial pass at a GNOME Print backend for
PangoPDF.  See the CVS link at http://pangopdf.sourceforge.net/.

At this point, the pangogp-to-pdf program in the examples directory
produces a PDF file.

Caveat hacker.

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

[xmlroff] GNOME Print backend for PangoPDF

[Tony G. <Ton...@Su...>]

I have posted some thoughts on the GNOME Print backend for PangoPDF on
the PangoPDF-List mailing list and the PangoPDF Wiki.

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

(but actually in Australia)

Re: [xmlroff] gnome-print [Was: xmlroff status -- 2003-03-21]

[Tony G. <Ton...@Su...>]

Tony Graham wrote at 26 Mar 2003 13:00:48 +0000:
 > Tim Waugh wrote at 22 Mar 2003 10:18:52 +0000:
 >  > I think that vendor packagers that would otherwise start looking at
 >  > code are probably put off right now by the fact that PangoPDF isn't
 >  > ported to gnome-print yet, and so can't be redistributed in a working
 >  > state in a commercial distribution as I understand it (IANAL). :-(
 > 
 > Owen Taylor conveyed similar reservations to me in December
 > w.r.t. Pango rather than commercial distribution.
 > 
 > FWIW, I have started.  In CVS, FoDoc is now an abstract type and
 > FoDocPDFLIB is a new child type.  I have also installed libgnomeprint
 > and looked at the example of tests/generate.c.
 > 
 > The next steps will depend on how much time I have to spend on it in
 > Australia.

Of course, any available help on this or any other aspect of xmlroff
would be appreciated.

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

[xmlroff] gnome-print [Was: xmlroff status -- 2003-03-21]

[Tony G. <Ton...@Su...>]

Tim Waugh wrote at 22 Mar 2003 10:18:52 +0000:
 > I think that vendor packagers that would otherwise start looking at
 > code are probably put off right now by the fact that PangoPDF isn't
 > ported to gnome-print yet, and so can't be redistributed in a working
 > state in a commercial distribution as I understand it (IANAL). :-(

Owen Taylor conveyed similar reservations to me in December
w.r.t. Pango rather than commercial distribution.

FWIW, I have started.  In CVS, FoDoc is now an abstract type and
FoDocPDFLIB is a new child type.  I have also installed libgnomeprint
and looked at the example of tests/generate.c.

The next steps will depend on how much time I have to spend on it in
Australia.

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

Re: [xmlroff] xmlroff-list on Gmane? Yes or no?

[Tony G. <Ton...@Su...>]

I have been twigged about one of my summaries of the DocBook
discussion:

Tony Graham wrote at 24 Mar 2003 13:46:36 +0000:
 > However, the DocBook list and/or the DocBook-Apps list is currently
 > hosting a sometimes heated discussion about whether or not Gmane is:
...
 >  b) Rude for ignoring no-archive headers

Substitute:

    b) Flawed for having a "14 days archive is okay" approach to
       'X-No-Archive: yes' and 'Archive: no' headers (see
       http://gmane.org/expiry.php)

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

[xmlroff] xmlroff-list on Gmane? Yes or no?

[Tony G. <Ton...@Su...>]

I have received notice that the xmlroff-list has been added to the
Gmane mail-to-news gateway/archive.  I have also been provided the
option of having xmlroff-list not listed on Gmane.

If you want to see Gmane in action, this post should shortly be
available at
http://news.gmane.org/thread.php?group=gmane.text.xml.xmlroff.general

However, the DocBook list and/or the DocBook-Apps list is currently
hosting a sometimes heated discussion about whether or not Gmane is:

 a) Useful

 b) Rude for ignoring no-archive headers

 c) A goldmine for spammers harvesting addresses

 d) All of the above

Presumably at least one current subscriber wants Gmane to gateway this
list.  Given that some people on other lists are strongly anti-Gmane,
is there anything approaching consensus on this list about whether to
Gmane or not to Gmane?

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

Re: [xmlroff] xmlroff status -- 2003-03-21

[Tim W. <tw...@re...>]

On Sat, Mar 22, 2003 at 08:28:10AM +0000, Tony Graham wrote:

>  > >    A by-product of xmlroff being open-source is that I am scheduled =
to
>  > >    taper off my involvement with xmlroff over the six months followi=
ng
>  > >    its release: if xmlroff hasn't been picked up other developers
>  > >    within six months, Sun isn't going to prop it up.
>  >=20
>  > I think it's a pretty exciting and useful project, so I
>  > don't expect it to die off. I'm not sure what you mean by
>  > "release", though; could you clarify? Does that mean 1.0, or
>  > is it something that has already happened? If it is in the
>  > future, do you have an estimate of when it might mappen?
>=20
> Released to public source.  The clock started ticking when the
> availablility of the xmlroff code was announced in February.  Right
> now I'm officially down to 80% working on xmlroff.

I think that vendor packagers that would otherwise start looking at
code are probably put off right now by the fact that PangoPDF isn't
ported to gnome-print yet, and so can't be redistributed in a working
state in a commercial distribution as I understand it (IANAL). :-(

Tim.
*/

Re: [xmlroff] xmlroff status -- 2003-03-21

[Tony G. <Ton...@Su...>]

Noah Levitt wrote at 21 Mar 2003 14:46:29 -0500:
 > Since you're doing me the honor of implementing my feature
 > request, I'll respond to your email. :-)

You've shown that you've used the software.  Right now that's a good
enough reason to consider your feature requests.

 > On Fri, Mar 21, 2003 at 17:24:35 +0000, Tony Graham wrote:
 > >    I am currently the only contributor to the Wiki.  Does anybody read
 > >    the Wiki?
 > 
 > A couple thoughts. One barrier to posting on the wiki is
 > that you have to feel extra sure you're not saying something
 > dumb. :) This can be a barrier to sending email to a mailing
 > list too, but less so, I think.

I can see that.  I would welcome discussion on either the Wiki or the
mailing list or both.  Right now I'm just trying to work out what will
work best.

I'm happy to continue doing brain dumps to the Wiki, but I'd like to
know if people are reading them, hence the original question:  Does
anybody read the Wiki?

 > On the other hand, I think people might be more likely to
 > contribute if the wiki were _the_ xmlroff site, instead of
 > being something else that is linked to from the site. 

That is an interesting point.  I hadn't thought of that.

Some things like the conformance page would be had to represent in a
Wiki, but if the Wiki were the main site, it would be easy enough to
link to those pages from within the Wiki.  What do people think?

 > >    A by-product of xmlroff being open-source is that I am scheduled to
 > >    taper off my involvement with xmlroff over the six months following
 > >    its release: if xmlroff hasn't been picked up other developers
 > >    within six months, Sun isn't going to prop it up.
 > 
 > I think it's a pretty exciting and useful project, so I
 > don't expect it to die off. I'm not sure what you mean by
 > "release", though; could you clarify? Does that mean 1.0, or
 > is it something that has already happened? If it is in the
 > future, do you have an estimate of when it might mappen?

Released to public source.  The clock started ticking when the
availablility of the xmlroff code was announced in February.  Right
now I'm officially down to 80% working on xmlroff.

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

Re: [xmlroff] xmlroff status -- 2003-03-21

[Noah L. <nl...@co...>]

Since you're doing me the honor of implementing my feature
request, I'll respond to your email. :-)

On Fri, Mar 21, 2003 at 17:24:35 +0000, Tony Graham wrote:
> 
> xmlroff Wiki
> 
>    I have recently added pages about debugging xmlroff, the fo:marker
>    formatting object, and building xmlroff.
> 
>    I am currently the only contributor to the Wiki.  Does anybody read
>    the Wiki?

A couple thoughts. One barrier to posting on the wiki is
that you have to feel extra sure you're not saying something
dumb. :) This can be a barrier to sending email to a mailing
list too, but less so, I think.

On the other hand, I think people might be more likely to
contribute if the wiki were _the_ xmlroff site, instead of
being something else that is linked to from the site. 

>    A by-product of xmlroff being open-source is that I am scheduled to
>    taper off my involvement with xmlroff over the six months following
>    its release: if xmlroff hasn't been picked up other developers
>    within six months, Sun isn't going to prop it up.

I think it's a pretty exciting and useful project, so I
don't expect it to die off. I'm not sure what you mean by
"release", though; could you clarify? Does that mean 1.0, or
is it something that has already happened? If it is in the
future, do you have an estimate of when it might mappen?

Noah

[xmlroff] xmlroff status -- 2003-03-21

[Tony G. <Ton...@Su...>]

Recent releases

   xmlroff 0.2.2, dated 2003-03-05

Changes in CVS

    - Added libtool library versioning to .so library file

    - Added pkg-config data file

    - Added libfo directory with header files and source code for
      simple and GObject-based interfaces to libfo

    - Added example xmlroff applications using new interfaces

    - Added FoMarkerParent type as half-step towards not failing on
      fo:marker elements

SourceForge site

   As of 2003-03-19, the xmlroff project had 3,226 page views and 442
   downloads and was ranked 2571 (which doesn't say much for the other
   55,674 projects on SourceForge).

   Corresponding statistics for PangoPDF are 910, 290, and 4664 (which
   really doesn't say much for the other 53,581 projects on
   SourceForge).

xml...@li...

   The list has 22 subscribers and has had about 50 messages to date.

   When posting to the list, 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.

xmlroff Wiki

   I have recently added pages about debugging xmlroff, the fo:marker
   formatting object, and building xmlroff.

   I am currently the only contributor to the Wiki.  Does anybody read
   the Wiki?

Sun and xmlroff

   The xmlroff project was conceived by Sun as an open-source project.

   The full name of the project is "Sun xmlroff XSL Formatter".  Among
   other things, the name format allays concerns about 'xmlroff' being
   someone's trademark.

   While Sun remains the main contributor to xmlroff (and, to date, is
   the only contributor to xmlroff), there's really no reason to
   change the name.

   A by-product of xmlroff being open-source is that I am scheduled to
   taper off my involvement with xmlroff over the six months following
   its release: if xmlroff hasn't been picked up other developers
   within six months, Sun isn't going to prop it up.

   I will remain involved with xmlroff, however.  Besides minor
   involvement in my Sun capacity, I am also registered on SourceForge
   in my private capacity.

Future Work

   There are 'To Do' lists on the xmlroff Wiki and in the source code
   distribution.  Does anybody read them?

   I am currently working on the font embedding feature request by
   Noah Levitt.  That's turning into a revamp of the
   PangoPDFLIBFontMap type.  I intend to post my thoughts on changing
   that to the PangoPDF Wiki.

   The areas that I want to work on after that are:

    - Improving the top-level API to support, e.g., reading and
      writing from filehandles and buffers

    - The 'border' property and other border shorthands

    - fo:static-content

    - The FO and Area Tree browser idea.

   I will be in Australia for all of April, combining both work and
   vacation. (I am also passing through Japan.)  I will, of course, be
   working on xmlroff while I'm working, and I will, at least, monitor
   this mailing list at other times.


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