.sla file structure

Previous topic - Next topic

Rob Dixon

Hi a.l.e

I did not say that I had made any money out of my database. Whilst it can process a huge amount of data produced by an enormous number of concurrent users, it only has a few million records to date. Its 224 bit address space is somewhat under utilised at present.

I should perhaps explain that I only want to create a pdf for a limited part of the database, for instance, for a printed catalogue. A user can make an interactive request for the data he wants to "export" from the database and can select at runtime whether this is to be printed on a PCL 5 local printer or output as XML. He or she can select certain options such as paper size, orientation, prime font size, duplex printing etc. for the printed output and others for XML. The printed output is typeset and of reasonable quality but not adequate for a polished professional looking catalogue.

We all have our skills and our limitations. One of mine is a total lack of knowledge or experience of python or scripting. But that doesn't seem to me to be my problem.  All I want to know is what style codes I need to include in the XML. I don't want to create a python script and if I could find the documentation for CAB="2" CCOLOR="Black" CBASE="0" CSTW="-0.1" CSIZE="12" CULP="-0.1" etc. I could include the necessary code in the XML without much difficulty.

I think that I understand all I need to know about outputting XML for my purposes. It is hardly very complex. I don't know much about processing XML.

Perhaps Scribus is not the right solution, but Adobe InDesign is expensive and I ideally want a generic solution for all applications that doesn't require users to purchase additional software.

If you don't wish to respond again, I understand. I appreciate your input to date. Where else can I go for help?





Nermander

It's most likely only explained in the Scribus sources, because it is only designed to be read by Scribus.

But I wouldn't expect to be able to take a structured XML file and apply style codes to get something out of Scribus. You could have to create (and place) a text frame for each page. This means you must calculate how much space your content will take.

I assume you have already found this page?
https://wiki.scribus.net/canvas/File_Format_Specification_for_Scribus_1.4

Rob Dixon

Thanks Nermander.

On the page https://wiki.scribus.net/canvas/Formatxml
it says
"The dimensions of the text frame are based on the live area of the document. That is the size of the page minus the margins.
New pages with connected text frames will be created while the current text frame overflows. "

I read from this that I won't have to fit my XML to each frame separately. Am I wrong? I have read something similar elsewhere.

I had found the page you identified but it meant nothing to me. It doesn't tell me what the valid values are for any of those attributes nor does it contain CAB="2" CCOLOR="Black" CBASE="0" CSTW="-0.1" etc.


Nermander

Quote from: Rob Dixon on May 31, 2016, 09:28:17 PM
On the page https://wiki.scribus.net/canvas/Formatxml
it says
"The dimensions of the text frame are based on the live area of the document. That is the size of the page minus the margins.
New pages with connected text frames will be created while the current text frame overflows. "

That is what the script does. The script creates frames based on the live area of the document.

If you look at the code you will see this part:

   def flow(self):
       while(scribus.textOverflows(self.name) > 0 and scribus.getTextLines(self.name)):
           current = self.name
           scribus.newPage(-1)
           scribus.gotoPage( scribus.pageCount() )
           self.name = self.make_textframe()
           scribus.linkTextFrames(current, self.name)


That code checks if the frame overflows or not. If the frame overflows this function is called:
   def make_textframe (self):
       margins = scribus.getPageMargins()
       size = scribus.getPageSize()
       w = size[0] - margins[1] - margins[3]
       h = size[1] - margins[0] - margins[2]
       return scribus.createText (margins[1], margins[0], w, h)


And here you can see that the code creates a text frame.

That script reads an XML file and the script explicitly creates the content in the Scribus document. The script creates text frames, and "types" the content of the XML file into the text frames. The XML is not "imported", it is parsed and handled by the script.

Rob Dixon

Nermander,

Many thanks again. If the script that you are referring to is the one from the Formatxml page, then that script didn't work and I was given another by one of the developers which did.

However, I am thinking of trying another approach. Since there does not seem to be any documentation on <ITEXT CAB="2" CCOLOR="Black" CBASE="0" CSTW="-0.1" CSIZE="12" etc., I had decided to create a Scribus document manually, making small incremental changes, saving the document each time, and inspecting the underlying .sla file to see how it has changed.  I won't find all the definitions this way, but I should find enough for my immediate needs. This may take a little while, but, for instance, I have already found that <ITEXT ch="Sample text."/>, without any of the above attributes is how Scribus saves simple standard text, so, for the moment, I don't need to understand the above options.

I think therefore that, rather than generate a .xml file, I should be able to generate a .sla file from my database without too much difficulty. My only concern is the header part of the .sla file, and for the time being I may just copy this into my generated .sla file in Notepad before I open it in Scribus. I will document what I learn and in due course post it if anyone is interested.

I have found that if you create a new document in Scribus with multiple pages and Automatic Text Frames set on, you can copy multiple pages of text from a .doc or other document in one go and paste it into the text frame on the first page, and it will automatically flow the text from page to page, without any problem. I think that this means that I won't have to do my own pagination, unless I want a mandatory page break.

If I generate my own .sla file, I will then be able to open it in Scribus and won't have to worry about importing it. I know that my version of a .sla file will have limitations and, to save time now, I will have to make compromises, but at least it will get me going. Once I have opened my .sla file in Scribus, I can make refinements to the layout in Scribus and then generate the PDF I need.

Are there any obvious flaws in this approach? I have moved to Scribus 1.5.2


Nermander

Yes, that might work.

But I think using XSL-FO would be way easier. And you wouldn't have to work against a moving target (the Scribus SLA format will most likely change in the next version).

http://www.codeproject.com/Articles/37663/PDF-Generation-using-XSLFO-and-FOP

Rob Dixon

Thanks but I want the intermediate step of being able to refine my document layout with Scribus before creating the PDF. In addition, I don't know Java (only javascript which is vey different) and don't wish to learn unless I really need to. My server is not Windows based but the really robust IBM Power system, running IBM i, and I am not aware that it will run java anyway (although it may do).

I think that my method, limited though it might be, will do all that I want and be much easier to implement that a Java solution, even if I knew that.

Rob Dixon

Nermander

A correction - Jave does run under the IBM i operating system - I have never used it

Nermander

You can most likely use XLS-FO without using java.

It seems to me that you have not investigated the options.

But if you want to be able to tweak the layout in Scribus after the conversion, why don't you for example convert to HTML or tagged text (using the text import filters that Scribus provides when you use Get text for a text frame)?

Importing tagget text content into Scribus text frames is a totally different issue to "creating a Scribus document from scratc".

Rob Dixon

Nermander,

Many thanks. My database does already create virtual web pages by generating HTML and Javascript on the fly. It also can generate XML and PCL 5 for printing. Because essentially the same code is used for all these options, it is relatively easy to generate at least the body of a .sla file and I actually achieved this in part yesterday. If I went on the XLS FO route, I would still be reading the manual. Of course, I still have quite a lot more to do,  but I am not displeased with my progress so far and I think that my chosen route was best for me. It would take me some time to explain the structure of my connectionist database.

In some sense I am importing tagged text into Scribus. You are right to say that I have not considered all the options because I did not know just what they were. You have helped.

Nermander

Well, XLS-FO is a "langugae" for attaching formatting to XML data. I thought that was exactly what you was looking for.

To me it seems as if you want to re-invent the wheel over and over. There are already tons of work put down into solutions to handle XML data and convert it to other formats. What would be wrong with trying to re-use that work instead of doing it yourself?

https://en.wikipedia.org/wiki/XSLT
https://en.wikipedia.org/wiki/XSL_Formatting_Objects
https://www.w3.org/TR/css3-page/

Remember that the SLA format will most likely change (again) in the next version of Scribus.

Rob Dixon

Nermander

Thanks for persisting with me. I don't want to attach formatting to existing XML data, but to include the formatting as I generate the XML and that, as I have already said, I have in part achieved. Because of the structure of my database, in which meta data is stored integrated with, and provides a context for, the user data, to include, for instance, basic style information in the XML is very simple, particuarly as I am already doing this when I generate HTML and PCL 5, using mostly the same code. I have a run time option that determines whether the XML output is for general use or for including in a .sla format file.