Author Topic: Scribus in a workflow? (text issues)  (Read 90 times)


  • Newbie
  • *
  • Posts: 3
  • Karma: 0
  • Probing Scribus
Scribus in a workflow? (text issues)
« on: May 09, 2018, 12:52:11 am »

I layout a scientific publication with not-so-many articles per year. For context, scientific articles are structured texts written/edited by external authors in their word-processors (usually .doc or .docx), some figures and tables with their captions and lists of formatted references/bibliography. Articles fit within a fixed set of few sections with a rather spartan design. Another article: iterate. Three things are crucial:
  • to keep a consistent design (master pages, styles)
  • to layout ilustrations among text easily (frames), and
  • to fully preserve (e.g., italics, subscripts, symbols) and layout (hyphenation, columns) text.

I've been hoping to move my complete workflow to open source since years. I've been working with Ubuntu Linux, Open/LibreOffice and Gimp since 2011, but I am still stuck building everything with PageMaker 6.5 (can you believe it? :o) running in a WindowsXP guest (in a virtual machine). Now a small window of opportunity opened and I decided to finally make the move to Scribus! :D

However…  :(

After some weeks of reading and trying (forum, email list, Mantis tracker, articles, manuals, wiki) I still cannot find a way to get text into frames and styles without losing all the work that have gone into building it in the first place, i.e., italics, sub/superscripts or small caps! I cannot afford to not only apply styles and manually check hyphenation but also to recover every subscript or italic that went there. It is a bit dangerous too. Nor I can move every author to use some particular markup codes instead of the "normal way" (like it or not) which would facilitate some import script.

I tried getting text from .doc/.odt and also .html, which seems to better preserve markup, but it all dissapear anyway when a Scribus (paragraph) style is applied. I found so many bugs reported through time (e.g., #477 in 2004, #9989 in 2011, #10661 in 2012, #12800 in 2014, #14916 in 2017…) and even reasonable solutions to the problem (several subordinated character styles for a paragraph style created when importing, I think in the email list from 2004!!!) that I cannot get how it was not fixed yet, as if it was some kind of optional feature. [rant] I know: "proper" italics vs "false" italics, "semantics" vs "appeareance", whatever... But how can Scribus be a "mature DTP" if it is (still) unable to properly import (formatted) text, which is the backbone of desktop publishing? That should have been the first task to accomplish, particularly because the (standard) recommendation is to do the heavy work on text (correcting, formating) previously in a word processor! [/rant] Sorry: I think I built so much hope for Scribus in all this time that now I feel really dissapointed…

Back to the point. Anyone can provide any solution/idea? Have anyone been able to put Scribus into a desktop publishing workflow that has (previously formatted) text as main input?

Thank you (and sorry, again…)


  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1441
  • Karma: 19
    • the graphics lab
Re: Scribus in a workflow? (text issues)
« Reply #1 on: May 09, 2018, 11:10:32 am »
the problem i see, is that people like you who have a real workflow

a/ do not get enough weight when setting the priorities for the scribus development
b/ do not put their money / energy into scribus to improve

there is not simple solution to this, but i agree that it's a shame that there is no documented / working way to get basic formatting from an editor into scribus.

personally, because of the type of documents i'm creating, i don't import formatted text into scribus and i have not much experience with it.
but for my old memories with pagemaker (have you already heard of it? : - )  a good way to solve the issue was to apply the paragraph and character styles in the editor before importing the text into the layout program.

i'm not 100% sure that will work well with scribus, but if you can try that out and check the multiple options available when importing, to see if it works or not then:

- you might find a workflow that works
- if none works, define one that should work.

as far as i can tell, it would be much easier to fix the importer (html or odt) to have a sane behavior rather than changing the way applying the styles in scribus currently works.

and yes, in my eyes the preferred way to import formatted text into scribus is odt, followed by html. we should take some effort that at least one of both works "correctly".

it would be nice if you could prepare a few simple odt documents with styles and document how they import into scribus if you want to match the odt styles with the .sla ones.
you could post the files and the results in here and i would for sure do my tests with them, too!




  • Newbie
  • *
  • Posts: 3
  • Karma: 0
  • Probing Scribus
Re: Scribus in a workflow? (text issues)
« Reply #2 on: May 09, 2018, 04:03:57 pm »
Thanks for your reply. And for the support.

Deal! I will. Not able to dedicate full-time, but I will search for those moments to advance neatly.

Things I noticed/read that made me guess that a bigger change in Scribus would be required (than just working with the import filter):
* the lack of "false" italics/bold (or buttons/shortcuts) to apply them once in Scribus [but sub/superscripts and small caps are available through the Properties window  ???]
* (single) Character style defined with/for each Paragraph style [i.e., "we don't want "false fonts" because they generate problems later, but we do not allow associations of "true fonts" so they can work as font families"]
* no recognition of Character styles applied in .odt/.doc source [but they are recognized/replicated when importing .html  ???]

I imagine Scribus may have implemented an "italics" button [and Ctrl+I shortcut] that instead of creating a "false font" would apply a subordinate character style within the same paragraph style, changing only the font variant [or refusing to do it if no proper variant is available/declared] in a similar way that dependent (paragraph) styles change when the parent ("based on") is modified. Same for bold. THEN the import filter can be fitted to recognize the source and apply the same procedure automagically. Same as Scribus should do when applying some paragraph style to text already in a Scribus frame (detect previous formatting => apply new style without "erasing" everything, plus an instruction/button to "erase all (previous) format" to apply when desired).

Anyway, I'll do my homework.

Chau  ;)