[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
 > 
 >