.sla file structure

Previous topic - Next topic

Rob Dixon

I am very much a Scribus newbie. I have my own database package that can generate XML and I wish to import this into Scribus. I think that I know how to do this (I have managed it once!). What I do not know is what to include in the XML for new line codes, style codes, etc. I could easily modify the database package to include whatever is necessary. I thought that I might find some of the answers on the page https://wiki.scribus.net/canvas/Formatxml as this contains a couple of simple samples. I assumed that the definitions of the styles "header 1", "body" etc. would be in
http://www.scribus.net/formatxml but that does not exist. Can someone please point me to documentation that will tell me how these features are structured in Scribus?

I posted this under Beginner Talk but didn't get any response.

Many thanks


creating and maintaining a dtd for the .sla file format would be a nice thing.

until such a documentation exists (in a format that can be use to validate files) i don't really recommend messing with the file format.

an alternative is checking the scribus scripter and see if it can do what you need or even improve to make it do it.

there are a few people who have put -- some time massive -- time into hacking directly data into the .sla files and:

- their work breaks everything time the team changes something in the file format
- most of those efforts are abandoned and unusable for other people (since they're tailored to a specific task)
- the scribus project at a whole, does not profit in any way from those efforts.

of course, you're free to create your own solution. but, personally, i prefer spend my time in tasks that make scribus better (or myself hapy... of course :-)

Rob Dixon

Many thanks. I haven't made myself clear. I don't want to change Scribus - I want to include in my XML the necessary code that will instruct Scribus how it is to display/send to a PDF the text.

I found a .sla file which contained, for example 

<ITEXT CAB="2" CCOLOR="Black" CBASE="0" CSTW="-0.1" CSIZE="12" CULP="-0.1" CH=" ${invoice.number}&#x5;" CSHADE2="100" CKERN="0" CSCALE="100" CSHADE="100" COUT="1" CSCALEV="100" CSTP="-0.1" CULW="-0.1" CSTYLE="0" CFONT="Times New Roman Regular" CSHX="5" CSHY="-5" CSTROKE="Black" />
Is this typical? It seems extraordinarily wordy (although probably very flexible) but surely this must already be defined and documented.  Is it always necessary to define all these values or do any of them remain valid until changed?

What do CAB, CBASE, etc. mean? What are the valid values? Is ITEXT Scribus specific or simply used by whoever created the file? It seems that CH is a variable but what does &#x5; mean? the length of the invoice number? What controls a new line and what controls the space between the invoice number and the next and previous fields? etc.

Any help gratefully received.


you made yourself clear.

and because that line is typical, i prefer not to spend much time trying to understand it...

Rob Dixon

Thanks but I am confused. If you know that that line is typical, how did you find this out and how did you find out what it meant? There must be documentation somewhere. I just don't know where. Please can you or anyone else help?


Quote from: Rob Dixon on May 29, 2016, 08:33:39 PM
Thanks but I am confused. If you know that that line is typical, how did you find this out and how did you find out what it meant? There must be documentation somewhere. I just don't know where. Please can you or anyone else help?

Probably the only documentation today is within the source code.

I have never dug into the format, but I remember that an object can be located anywhere in the SLA, the page where the object is placed is a property of the object and does not depend on the structure of the SLA. This means that to move an object to another page, you just change a property of the object. You do not have to move anything within the SLA to move an object to another page.

This might have been changed the last years, I know there have been projects to improve the structure of the SLA format. But the SLA format is not (yet) intended to be human-readable.

Rob Dixon


Many thanks. I know that you think that I am following the wrong route but I still want to give it a try, at least for a small document. I don't quite understand quite how Scribus exists if there is no documentation. I don't know how many programmers were involved at the beginning but they must have had some form of instruction. Do you know if there were specifications before coding began or at least ambitions?

In addition, what is the point of having the ability of importing XML if you cannot do anything with it?


Scribus is still in development, there are many things on the wishlist.

From what I understand the SLA format was not made to be "structured", it was just convenient to use XML because it is an open format and there were good libraries to read and write XML. But I think the SLA format intially was just a way to "dump" the internal working format om Scribus into a file. That is why it is awful to work with.


hi dogil,

scribus has of course documentation for the users.

and there is also some documentation for the scripter.

but the .sla file is indeed mostly undocumented.
there are some efforts being done (also by myself) but as you can see from your own behavior it's very hard to get people to help out and contribute to something that really improves scribus.

btw, you *can* process xml from scribus! just not outside of it, but inside of it.
just write a python script that you run from inside of scribus, use a python library to process xml, manipulate a scribus document, produce a pdf.

sadly, most people prefer to go for a quick and dirty external processing that will be by its own nature short living and too few people help maintaining and extending the scripter.

Rob Dixon


Surely someone must have defined the structure of the sla format or was it just one coder working by himself?



yes, it's mostly one coder doing some work and then asking for feedback on the solution he is proposing.
if nobody raises his hand, he goes on and the code gets merged...

scribus has a small team... and, sadly, exactly because of the things you're pointing to, it's hard for new people to get in...
some manages to do so... but it's a steep climb...


Rob Dixon

Hi a.l.e

Many thanks. When I generate XML from my database package, at that stage it has a context so that I know what styles, etc I wish to use and could insert them into the XML, but, if the XML has already been exported, the context will have been lost when it is imported to Scribus so a script would not know what to do.


hi rob,

if you miss that context, you're probably doing something wrong (like not storing the context in the xml).
hard to say what is not as optimal as it could be, without knowing more about what you are doing.

you also might be able to directly query the database from the python script, if python has bindings for it...

Rob Dixon

Hi a.l.e

I patented my database so can claim that it is unique. It is a connectionist NOSQL multi-dimensional database which stores all meta data and user data in one integrated contextual database. It is not a flat file - all attribute iterations are indexed. Both customer and product may have an attribute "name". The database stores separate contextual definitions for the two attributes called "name".  In XML, you could have <customer><name>smith</name></customer><product><name> etc. and I guess that a script could be written to handle this if, say, customer name was to be in bold, etc. But there are an unlimited number of possibilities and a script to handle these could not be universal, and, as far as it went, it would be duplicating the information already in the database. The database is universal and new entity types, attribute definitions and application definitions can be created without any coding as the definitions are stored in the database, rather than in program code. The database is designed for massive data volumes and enormous numbers of concurrent users, and the almost zero second response time does not noticeably change as data volumes increase.

I need to find a way, if possible, of putting style values into the XML - I cannot imagine any other solution, other than importing the XML into Scribus and then doing all the work on styles etc. manually, within Scribus, but this would be very time consuming and a waste of time.

Does anyone have any ideas please? It seems to me that sla is so basic to Scribus that it is hard to believe that there is no documentation of its structure.


sorry, you created and patented your unique database and now are you asking -- well almost requiring -- me / us to provide you help for free?

... you created the most astonishing and powerful database and you're not able to create a simple python interface for it? and you're relying on random users on the internet to solve your problems?

please hire a consultant who has a clue about how to process xml data to produce formatted documents out of it.

if you have to process a huge amount of data produced by an enormous number of concurrent users, the least of your problems is to grok how to get a few fields into the scribus .sla.

how do you think you're going to get scribus to produce pdfs out of that massive amount of data? mmmm...
i'm really not sure that scribus is the right tool for the job...
while it can do some automatic processing of data, it's a tool that has been created for interactive usage!

really, if you think that scribus is the tool you need (and in most other cases too, if you want your xml to be processed by external libraries / applications) you should look into your database and check how to tweak it to put in the xml all the information needed to further processing the data.

i don't know, as long as you don't tell us what you're up to, it's really hard to help you.

that was my last reply on this topic, except if you give very good reasons (for me!) to engage further in an issue that i see as hopeless.