[xmlroff] Using libfo in a Scribus XSL-FO import plugin?

[Tony Graham]

On Mon, Jun 30 2008 10:58:29 +0100, elvstone at gmail.com wrote:
> 2008/6/29 Tony Graham <Tony.Graham at menteithconsulting.com>:
>> On Sun, Jun 29 2008 12:33:38 +0100, elvstone at gmail.com wrote:
...
>> I really don't know what is involved in making a Scribus plugin for
>> libfo.
>
> Yes, sorry. Well Scribus is, from an import plugin writer's point of
> view, basically just a canvas on which you absolutely position objects
> such as images, text frames, basic tables and other shapes. For text
> frames it has support for paragraph styles to control paragraph
> properties such as font, line spacing, et.c. Anyway, I guess this my
> first question was pretty vague and useless :)

It was a good place to start.

I've now found the plugin howto [1], but haven't read it all yet.

I see there's also a Get Text plugin [2] option.

What is the purpose of the plugin?

Does the plugin drive Scribus (as you seem to describe) or does Scribus
drive the plugin?

What is your expectation of round-tripping between Scribus and libfo?

If it is essentially import-only for Sribus, then it may be possible to
make Scibus look like a subtype of FoDoc such that libfo "draws" to
Scribus and then finishes.

...
>>> I have a general knowledge about the formatting process of an XSL-FO
>>> formatter, and I know how formatting objects are broken up (or smashed
>>> together?) into areas and traits in an area tree. But I'm not quite
>>> sure what information is contained in this area tree, how much of it
>>> is accessible using the libfo API, or if it will be of any help in
>>> laying out pages, texts, images and tables in a Scribus document.
>>
>> The libfo area tree has all the information about positioning on a page,
>> but information that doesn't change, such as colours, is just in the FO
>> tree.  Some work that I don't think I've checked in anywhere is to
>> implement a GObject interface for the common border and padding
>> properties (and, eventually, the other common groups of properties) to
>> make it easier to access the FO.
>
> This is good news I think. But are you saying there's currently no way
> to access these common properties you speak of using the libfo API.

You can get to them, but sometimes you have to use the generalised
GObject property functions since you shouldn't need to know the exact
type of the formatting object that generated the area.

E.g., from libfo/area-to-pdf.c:

      g_object_get_property (G_OBJECT (fo),
			     "border-top-style",
			     &value);

It doesn't matter what type of FO generated the current FoArea since, if
the area can have borders, it's certain that the FO has the properties
for borders, and all the XSL properties are accessible as GObject
properties (and, yes, the overlap of terminology is sometimes
confusing).

The closest this comes to being documented in the xmlroff reference
manual is in fo-h-file.html#fo-h-property-functions and in the
"Properties" section on the page for each FO.

You are welcome to point out deficiencies in the documentation, and even
more welcome to provide text to plug the holes.

...
>>> This may be a very hard task, but that's why I found it interesting
>>> and volunteered to help, to the best of my abilities :)
>>
>> You should also look at which FOs and properties are currently
>> implemented to see whether libfo does enough to be useful.
>
> Yes, I know xmlroff isn't full featured yet.

Plus there's still work to be done on memory leaks.

Regards,


Tony.

[1] http://docs.scribus.net/index.php?lang=en&page=plugin_howto
[2] http://docs.scribus.net/index.php?lang=en&sm=gettexthowto&page=gettexthowto