LGM 2011

From Scribus Wiki
Revision as of 18:22, 10 May 2011 by Malex (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Notes from the 'Scribus meeting'

Scribus meeting 2011

Present: Pierre Marchand (dev Scribus, artist, OSP), Peter Linell (dev, documentation), Christian Ambaud (OIF), Ludi Loiseau (designer, OSP), Femke Snelting (designer, OSP, Constant), Andreas Vox, Jean Ghali, Cedric Gemy (designer, author), Claudia Krummacher, Greg Pittman (python, documentation, tinkerer), Kai Uwe Behrman, Diane Beausejour (?) (ICGQ), Ale Rimoldi (bugfixing, community work), Olivier Bertens (Swatchbooker), Heidi Strohm (graphic designer), Ricardo Lafuente (Manufactura Independente, designer, LG-magazine), Ana Carvalho (Manufactura Independente, designer, LG-magazine), Tom Lechner (artist, developer Laidout)

Current 1.3.3.x and Scribus-ng 1.3.x Scribus *almost* removed from Ubuntu because it did so poorly. Please make a distinction between 'scribus' - 1.3.3.x and scribus-ng 1.3.x on Ubuntu. Ubuntu had a very buggy 1.3.5 for a very long time - a product of their release schedule disconnect from Debian's freeze. Both scribus and scribus ng are 1.4.0rcX in Debian/Ubuntu now, so let's move past 1.3.3.x.

Peter Linell: "Our hands are tied"

Question Ricardo: we upgraded etc. but it seems the only way is to move to another distro? (Yes. There is no quick fix) Tell him if they like debian/ubuntu then they really must use Debian in a production environment because of its better stability, being more amenable to a business setting and better scribus support. Ubuntu is too much of a moving target to be a viable business distro with good support for tools like Scribus - leave it to people tinkering with their computers and admiring shiny interfaces. It's just going to get worse as they completely move to Unity interface because Scribus with its many palettes will likely not work well there.

Upcoming 1.4 final branch


Pretty stable; in good shape; almost there (real life got in the way of getting it done for LGM2011). Moved Scribus to QT4 -- take advantage of features. Is superior on OSX. Drag and drop in OSX still problematic. Text undo almost there! It was a big patch so it unmasks other bugs; problems in Ubuntu (only). Ever present ARM/ARMEL build problems due to qreal float/double conversion.

New text layout engine, so it is faster10 page limit on OSX needs to be solvedOSX Packaging needs to be addressed a bit more formally 1.5 branch

[fall 2012?]

First Scribus to support non-latin scripts Important to make more people to participate. 2 new people seem to be ready to join. We need to start accepting git commits to lower the entry barrier for new people.

Colormanagement rewritten from scratchSupports lcms versions 1 and 2Implementing changes from OIF-branch: palettes are dockableLayers: masterpage-elements can be in front or back; are a property of masterpage: pagenumbers can appear in front for exampleWe expect both 2011 GSOC project to be mergeable in fallTable-editor (GSOC / should be in 1.5 in fall)2nd GSoC project: complete Scripter NG (python + QtScript / PyQt)Symbols - linked scrapbook elements; a change"Groups are real items" (?) Kai Uwe: Question about colormanagement


make composition engine more robustRe-implement non-square text frames etc. More on this: http://www.libregraphicsmeeting.org/2011/day-4#JeanGhali

It should have been more public ... it is time to talk about it, how people can contribute to it. Greg: What are we doing to really invite people in? PM: there is room for improvement. Had a crash ... part of files are saved.

OIF and 1.5 will meld at some point. First parts of 1.5 have already merged into OIF branch. Greg: What is happening to Arab ... are problems fixed?

1.6 release plan

Breaking barriers to participation Need to create an easier way for outside people to contribute to Scribus development. That might mean adding use of a distributed RCS, clearer documentation on how to contribute.

Additional issues, ideas Ale: colleague sending code for launching Scribus from commandline Ale: a blog to do quick notes, log all features found. Louis: can we already do that now? Ale, please elaborate.

User feedback

[see below for overview of issues]

Feedback from Libre Graphics Magazine (Ricardo) Updating text frames when content is changed The issue of styles ... rethinking styles is needed ... PM: we're already thinking about this ... xml-based? Commandline export we seriously need -- to connect to git. Ale: proposing a synchronisation solution? Markdown? Greg: .sla is complex; so not easy to reproduce how to go in-and-out to Scribus. Avox: xml + css (a subset of 2.1 + Scribus extensions) will be file format for story editor. You can edit xml, you can have different styles for different outputs. RL: Text becomes a resource like an image. Louis: text is different than image; should be an option. Possibility to 'embed' text (get text, like now or have 'live' text). PM: would we only have one representation of the text (ref: problems of style-duplication). Avox: import external stylesheet, but not exported. Text and structure could be edited two-way. Middleware ... a text representation of the styles. Replicating web-based styles... Louis: Why would you want an external text-file? RL: if there is a correction ... we need to do everything again. We could just update the text/xml file and we would not need to open the document, or even worse: to re-apply the styles. Greg: just search + replace the .sla RL: Editors can't work with .sla; making small corrections (typos, etc) doesn't need designer input most of the time. Our ideal workflow is that editors could make changes, commit to git, and have a git commit hook that converts .sla to .pdf automatically when a commit is made. (PM: you need to check it) we want to check the pdf, not the scribus document -- it's a lot faster to open a PDF viewer. Most of the time changes are small enough not to disrupt the layout, and when it does we can open Scribus and fix it. (sidenote: If you have more than 1 person editing the text, it becomes hell to keep updating+re-exporting a Scribus document. Right now we have to hold the layout part until most editing is complete; ideally, this wouldn't be necessary with the editors feeding in their changes and the Scribus file incorporating them automagically.) Plug in git as the back-end - with a couple of forms to see diffs editors/writers could do very well. [this is thought for 1.6; maybe Ale solution is quick fix] In the text-editor you can not add char styles (can do paragraph styles). Don't forget this for the new story-editor! (working on Canvas less responsive). How to make style-changes visible in text-editor (like in this titanpad :-)) Master-pages layers is *much* appreciated! Ale: quick fix ... mix schrapbook and masterpage.

Feedback from OSP (Ludi) Ludi: I met the same issues. I am happy with xml ex-import, and the other issues Ricardo and Ana bring up. Question about text-flow around shapes. I was working with it for a novel ... and experienced strange artefacts, hard to adjust. It is electric; there is compressed text happening. PM: I was in this book as well -- I did a patch; Scribus will try to display a letter ... in a column you could have letters on their own in a line. This bug is actually a work-around for Japanese type-setting! PM will figure out a proper fix; the text editor assumes that everything is in Latin. Flowing text ... is there an option to flow text on let's say only odd pages? Ale: you can create a chain with odd/even pagenumbers ... Or a script Ludi: but not an option if I have 200 pages? FIXED! ("this bug has become a feature through documentation"). Discoverability of features ... <- that's why we worked on making wiki the center of all documentation efforts - should be easier to represent changes.

Feedback from LGM-brochure (Heidi)

Importing text made Scribus text (using 1.4.3 on Mac) PL: thought we fixed that!Guides should always be visible -> really? why? there is a choice...Unexpected behaviour of sidemenu --> part of reworking paletteWhen I select and replace text, I expect it to stay with the style I copied it from. Text-editor awkward; don't want to look at ALL my text if I am only change one frame. --> you don't have to use it ... it is faster ... Click-and-drag is unreliable ... --> it is best to use shift [times up!]

Overview of issues by designers involved in Libre Graphics Meeting:

Master page elements are now playing with layers. That's great. Thank you Jean.What about the "habillage" on text (text flow around shape) ? It sometimes compress the letters. That's really hard to precisely adjust.Thin spaces by default ? (when they are not included in the font) I think I already did that -- nope, not in SVN yetplease add thin spaces... when I put a smaller size on spaces to fake a thin space, all those changes are lost when I re-open the document.Automatic text flow on one page ? (even and odd pages)Text-boxes in masterpages ('dynamic elements')Undo on text is *essential*Question: Scribus, lcms, lprof, etc need to standardize on color profile usage, so that color profiles could be distributed separately from all those software as they are often under completely different licenses - problematic for Debian for instance.Question: Is it, or would it be possible in the future, that the contents of a text box filled with "Get Text" are updated when the source text file changes? One more: how could we make this work with styles, e.g. italic text or titles? RTF import? Markdown? (better) New text engine will support XML+CSS as external documentsWe *NEED* to be able to apply _character_ styles using the text editor. Not possible at the moment, unless we're not looking well enough. Story editor will be rewrittenunbreakable spaces sometimes are larger than a normal space, is this because of the font? possible. Whcih font is that? several fonts, I just tried again with Latin Modern Scribus 1.4 or Scribus 1.5?1.4 rc2 on debian ppc. maybe it's just the font if no one else saw that...make the story editor more *coherent* with text options from the Properties window (ex. cannot apply character style, cannot change line-height...)being able to override all paragraph/character styles (text indent for ex.)strike-through, underline using a different color than text, so it's handy to make colored blocks of textfootnotes?being able to turn the page around? explain that? I am working directly like a signature sheet. one side is a booklet and the other side is a poster. I have text upside down :) and cannot apply character styles in story editor... so another way would be to see it upside down. like you would have a sheet of paper in front of you, and you turn it 180 degrees, or 90 degrees... Ah, now I see :-) I think we talked about that before: rotating the canvas. ok, and what's the conclusion? We will implement it at one point of timegreat :)being able to link to text files would be a huge thing, especially using markdown for basic formatting!Incoherence between display (font, size) of styles in story-editor and properties palette T H A N K YOU SCRIBUS