Render box in separate file

Previous topic - Next topic

Twain1

Is possible to store any code of render box in separate file?
example:linking tikz file inside scribus file?

dragonfly

My first thought is to use a script such as https://github.com/berteh/ScribusGenerator to refer to external resources through VARS.


dragonfly

By a very odd coincidence I have only recently returned to this forum to explore ScribusGenerator in a rather complex workflow I am dreaming up. And I am looking at ScribusGenerator architecture right now.

It is a very useful tool for the examples cited but it is limited in merging very long strings in variables and as you write remote files held elsewhere. I decided to experiment.

First the spreadsheet example shows a longtext example but it is not practical to squeeze long text strings or other content into a single spreadsheet cell. So I had the idea to use a string of indirections. Let me explain.

In a spreadsheet you can have any cell created from formula referring to other cells.  So the first cell can have a formula which points to another sheet/cell and so on.

In my case I have markdown files which have long blocks of content and I want to create a ScribusGenerator %VAR_text01% which in fact points to a script which in  turn converts a markdown file held in desktop.  In other words a pipeline of indirections.

Similarly %VAR_text01% might point to a script which uses curl to scrape text from a site. Or the script might extract content from a mongodb database.

I hope I convey the general idea. Use as many levels of indirection to grab the content to place into SLA objects.

Another tip is that using ScribusGenerator I am also embedding php scripts into SLA objects so that at the closing end of the workflow the SLA can be parsed again to expand into the final layout.  In this way "php include" can be used as %VAR to import remote content from say ASP.NET (in your example).  I can expand further on this pipeline idea if anyone is interested.  It seems a complex workflow but it works.  My pipeline starts with Atom editor (it can run in cross platform) to create markdown pages and I can preview content long before it is piped into Scribus via ScribusGenerator.

The broad theme is that Scribus should form part of a toolchain for document production.

In my case I start the pipeline using Atom editor (with markdown packages installed), pandoc, LibreOffice Calc, Inkscape (svg can be imported into Scribus), Scribus, ScribusGenerator, python scripts.  Other tools might automate the navigation of Scribus GUI.

a.l.e

hi

i just skimmed through your post, since i'm not too interested in workflows that modify .sla files from the outside.
i consider those tweaks fragile / dangerous and i prefer to focus on wokflows where scribus is used to layout the content and produce the pdf.

personally, i've started creating a mail merge functionality in python that works from inside of scribus.
if i recall correctly:

- it's in a good state and works ok for several workflows.
- at some time (maybe in the near future) i'd like to extend it to match the features of the scribus generator.
- at some time i plan to create a gui for creating an ad hoc configure file.

not sure this is what you need, but maybe the code i've written can be of some help for you.

dragonfly

@a.i.e

I do not visit this forum often but I must defend the principle of "mixing and matching" multiple tools to achieve an end objective.

Too many applications take the view that everything must be improved from the inside by either writing new features or packages or extensions rather than using a toolchain. Atom is an example where over 8000 packages have been developed by that community. I use Atom editor to produce the raw content but I prefer to write my own external scripts because I can never be certain that the community package developer still supports the package. There are a number of notable exceptions to this rule.

Take Scribus itself. Simple PDF documents can be created using pandoc from markdown.  But to go to professional print quality rquires more work to use Scribus.

In the case of ScribusGenerator the author is simply leveraging the benefits of Scribus SLA being xml format. If you get to around 18.30 in his tutorial he begins mentioning xpath and customising xpath attributes such as fonts.  This is readily done in Python using xml.etree for example.  I do not view this as tweaks. It is a serious parsing exercise to bind external resources to xml elements.

Take any SLA file and open it in XMLCopyEditor and we have another means of editing the innards of SLA.

And again if we consider Scribus Generator is only used for "mail merge" usage we are missing the point.

We can use the same binding workflow to create different versions of a Scribus document perhaps in different languages in text boxes with personalised titles and images..

My understanding of parsing xml by embedding php came from reading this old blog.

https://old.carto.net/papers/svg/samples/serverside_svg_php.shtml

Here instead of %VAR_something% as in ScribusGenerator we see PHP clips inserted. we have then use PHP to import content and assets.

I have tried this with SLA (changing extension to *.xml) and it works nicely. Thus we can be developing Scribus documents in a PHP server.

Yet another approach is to use external tools to navigate the Scribus GUI for automated entry of data. In fact in another thread you refer to testing the Scribus GUI using tools such as xdotool. So here we look at other tools such as Selenium.

I rest my case.

a.l.e

hi dragonlfy

i fear you're preaching to the choir...

i'm a big enthusiast of using tools that are as small as possible and would love seeing scribus shrink a bit,  focusing on a clear goal and refrain from providing features for everything (and improve what already exists and add general interfaces to the external world).

on the other side, the .sla file is an internal file format for the scribus application and there is no promise that modifying it will lead to a sane result.
and in my eyes it's not a really beautiful format.

for these reasons, i really prefer letting scribus mess with writing and reading .sla files and use (and extend) the official python scripter API to interact with the scribus features and through the scripting open the gates for the communication with all the tools you can think of.

imo this way leads to durable improvements to scirbus and provides new features that are there for everybody to use for their own interactions with scribus.
scribus should not do everything, but it should provide interfaces that allow me to do everything in a safe way!

the result is that i can work in a sane and clean way and everybody else will profit from my effort.
that's one of the big advantage of free software: you don't have to hack around the tool, you can hack the tool itself!

of course, you're 100% free to go down the rabbit hole and do xpath transformations on .sla files!
(greetings from a guy who has created a php tool that used regex to convert rtf files into html!)
but, personally, i would love it, if in the future the scripter api would provide a way to parametrize svg drawings that are embedded in a scribus document!

dragonfly

@a.l.e

I am going down another rabbit hole.
Let me share with you a journey.

We will explore the world of semantic analysis - in this case analysing the ugly SLA language (xml) inside Scribus documents.  Now all semantic strings we view are separated by delimiters such as space characters or in the case of SLA we search for = character as delimiter.

Install AntConc from here.

https://www.laurenceanthony.net/software/antconc/

This is a true power tool.
Open the AntConc window.

Now take any sample SLA file as a test.

File > Open File(s)

Navigate to the folder containing test.SLA

Now AntConc usually expects txt files but we can choose

Files of Type: All Files (*) and choose test.SLA
Or easierwe can clone the test.SLA file to test.TXT.

The file is now seen under Corpus Files window pane.

Now in search term type = which is the delimiter we choose for all strings.

Choose also Sort by Word. There are three modes to choose from ..

Sort by Freq
Sort by Word
Sort by Word End

Click on Start

We see four columns


Column 1 - Rank which is just an index.
Column 2 - Freq which is frequency of occurrence of Words.
Column 3 - Words found from search.
Column 4 - Blank since no "lemma list" has yet been applied (advanced option to be discussed later)

Now scroll down the Word column to look for words of interest. Later we can filter out unwanted words in our search.

Remember that separators of interest can be space or = sign (in attributes).

The most useful delimiter is the equal sign = so we will search for that character.

Also in Tool Preferences > Concordance we tick Other Options > Treat case in sort.
This ensures that search is case sensitive.

If this document is searched ..

https://www.laurenceanthony.net/software/antconc/releases/AntConc343/help.pdf

for delimiter we read

Use the "Delimiter" option to select the delimiter character.

If we click on any word we are taken to its position in the ugly SLA format. we can quickly edit internal attributes in this way bypassing the Scribus GUI.

We can customise searches using separate files containing the attributes of interest.

In other words we create a whitelist and blacklist.

Here in this rabbit hole we are exploring semantic analysis tools..

It would be useful to reference a list of SLA attribute titles (words) to customise searches.
We can then use the Advanced Search feature.

There are archived nuggets of information found here on dynamic layout support.

https://wiki.scribus.net/canvas/Dynamic_Layout_Support_Discussion

=============================================

On the issue of customising SVG files it seems that Scribus imports the rendered SVG file. thus clear test words (such as %VAR_title% ) cannot be searched within an SLA file to be processed by ScribusGenerator.

What can be seen are broad attributes such as ..

gXpos="111.752" gYpos="87.099" gWidth="376" gHeight="197" LAYER="0"

But the internal objects inside the imported SVG cannot be processed.

What can be done is to use the %VAR approach to customise SVG in an external SVG editor and then export a series of customised SVG files.  Then the task inside SLA is to have a variable which points to the appropriate SVG file to import.


a.l.e

hi dragonfly,

sorry, i did  not understand your two parts on dynamics.

but i try do give some personal insight on the bits i think i did understand correctly.

* * *

if you want to put an svg into a scribus file:

- you cannot just put it into it.
- if you use xml transformations to convert svg into .sla, you will be missing all the efforts scribus does, to ensure that the whole document is sane (color management, font management).

* * *

if you want all the words in a scribus document, there is a simple script that exports the content of all the text frames into a text file.
if you want, you can build a proper xml file instead.
no need for complex xml transformations on the .sla file.

* * *
if you just want to do "statistics" on the items inside of scribus just ask scribus what the document contains. you can even do that "from the outside"(launching scribus from the command line).
you can then throw all the tools you want at the data you collected that way.
even use xml for it.
and re-read the processed data into scribus to modify the document.
(been there, done that... of course. it was pure txt and no xml, but i have provided a translation solution for a specific scribus document: exporting all the content with some metatadata and reimporting it after the translation)
and if you're missing some interfaces in the scripter API, you're welcome to ask for it or -- even better -- add them yourself and contribute them upstream.

* * *

if there were more people hacking on scribus, i would be delighted to see your efforts around scribus.
but in the current state where we badly need people to help out improving scribus, i feel sad when i see how much effort people can put in (often very interesting) adventures that produce small (or big) fragile islands of code that do not improve the ecosystem (the generator is probably the only one of those efforts that does give something to the community and has lived on for years... but even in that case it would have been so much better for the users, if it would have run inside of scribus).

as said, you're free to do as you see fit, i only wanted to hint you to the "delicate" parts of it and how you could do it so that the whole scribus ecoystem i think  can profit from your efforts.

ciao
a.l.e

dragonfly

@a.l.e

Thank you for your valued insights. I am busy on other matters right now but when I have more time I might take up your suggestion to explore Scribus inner workings - starting with using Scripter rather than the nuclear core.

Just one closing point of explanation. When I referred to analysing concordance of "words" i was not referring to the English or other language words in textframes but rather the "words" seen in a template SLA document. We can access attribute names such as gXpos= and many others.  Here is a line in a raster frame ....

<LATEX ConfigFile="100_latex.xml" DPI="0" USE_PREAMBLE="1">

and I might search for all occurrences of LATEX to edit the source.

But I think that the spinoff needs to be demonstrated rather than discussing this whacky idea further. I am just an experimenter.