Scribus > General Discussion

Scribus in a workflow? (text issues)

(1/3) > >>

FairMiles:
Hi.

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…)

a.l.e:
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!

deal?

ciao
a.l.e

FairMiles:
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  ;)

 

FairMiles:
OK, this is my report of explorations for a workflow to layout a scientific journal starting from (incorrectly) formatted word processor documents by external authors. Tested with Scribus 1.4.6 in Ubuntu Linux 16.04 (+ LibreOffice 5.1.6.2)

1 - Text document received as .doc or .docx with no (or uncontrolled) paragraph styles, a general font (Times New Roman) and direct formatting applied in the word processor (italics, superscripts, bold, small caps)

Workflow A1: Practical, Scribus-intensive (in MSWord+PageMaker style)

2 - Document opened/imported in LibreOffice Writer and saved as .odt. [example: MStest.odt]

3 - Template in Scribus with master pages, paragraph/character styles and text frames [example: Hornero artículo.sla]

4 - Text inserted into Scribus text frame (Get Text…; no overwrite or merge styles; styles imported with odt name appended)
   (a) Importer: OpenDocument Text Document
      -> All direct formatting is recognized, including italics and bold (i.e., using family fonts)
   (b) Importer: OpenOffice.org Writer Document
      -> All direct formatting is lost

5 - Scribus Paragraph styles applied
   (a) in main window (editing frame contents + options in Properties|Text)
      -> All direct formatting is lost: Character styles must be reapplied to italics and bold texts + Superscripts and small caps must be reapplied as direct formatting  [+ Character styles must be defined completely for each paragraph style (no partial/relative changes or hierarchy)]
   (b) in Story Editor (options in top bar)
      -> Direct formatting such as superscript and small caps is preserved BUT some characteristics of Paragraph Style (e.g., font) are not applied to text in italics or bold (?!) + Character styles cannot be applied directly nor searching and replacing.

Workflow A2: Scribus-intensive based on .html (in MSWord+PageMaker style)

2 - Document opened/imported in LibreOffice Writer and saved as .html [example: MStest.html]

3 - Template in Scribus with master pages, paragraph/character styles and text frames [example: Hornero artículo.sla]

4 - Text inserted into Scribus text frame (Get Text…)
   (a) Importer: HTML Document | Need to define replace fonts for html fonts, such as "bold" or "bold italic" (editable in File |Preferences|Fonts|Font substitutions or/and File|Document Setup|Fonts|Font substitutions)
      -> All direct formatting but Small Caps is recognized, including italics and bold (i.e., using substitution fonts as defined in Preferences)

5 - Scribus Paragraph styles applied
   (a) in main window (editing frame contents + options in Properties|Text)
      -> All direct formatting is lost [see above]
   (b) Paragraph styles applied in Story Editor (options in top bar)
      -> Direct formatting such as superscript is preserved, text in italics or bold remain as substituted when imported + Character styles cannot be applied directly nor searching and replacing.


[to be continued: Workflow B: Text styles applied in LibreOffice Writer]

mnawij:
Hey a.l.e.

Just a quick aside, is there a way for Scribus to import an .xml file that saves the formatting since .sla file are saved in xml?  I know both Word and LibreOffice can write xml files... would it be possible to code the MS Word importer from LO and then write out an xml file from LO export?  I have not taken a coding class since 1993 so I might be a bit rusty on the logic possibilities.

FairMiles, I am 100% in agreement with you on this issue.  As someone who has been trying to move to complete Open Source apps for my business for a couple years now, this is one area that really needs to be updated.  This is one of a handful of issues that needs to be implemented in Scribus before I can switch away from Adobe apps for my print shop.  I get at least a dozen or more Word files to work with each month to convert to InDesign currently.

Regards,

mnawij

Navigation

[0] Message Index

[#] Next page

Go to full version