Google Summer of Code 2007 projects ideas

Here is a list of projects that could be done during Google Summer of Code 2007.

Scribus Team Ideas

Imposition

Write an imposition (booklet printing) plugin for Scribus.

Background Information

About.com

Text merge

Write a text merge plugin for Scribus. This would allow to read data records from a table and use it for text content or filenames for image frames. It could also provide a mode to print labels etc.

There is a mail merge RFE. One of Czech student is working on it. It looks like it will turn into common usable text merge from various data sources (CSV, XML, db...) --Subik 13:05, 7 March 2007 (CET)

End-to-end publishing solution

LiveCD

Live DTP CD or DVD – this draft/project is 2 years old and should be reviewed first, but there is definitely a need for such a solution.

Blue Sky Ideas

Present the title of your idea here and link to the wiki page where you elaborate on it.

twexter

twext texts provide comprehensible input for language learners, and can integrate will many softwares (including MediaWiki and/or the wiki for the $100 laptop ).. why not a twexter plugin for Scribus?

Tales from the Crypt, a.k.a. Ideas from the Bug Tracker

XML Editor

#1394 XML Editor
Related to #5190
Related to #2108
Related to #1791

It could be practical to have an on/off toggle in the text editor between Wysiwyg and some kind of XML. One click you have the classical way to type text, Another one, formating disappear, XML tags appear like this :

-------------------------------------- <font name="Bistream Vera Sans MS" size="10"> blah blah blahalahb blah blah </font> <justify>blih blih blih blah blah</justify> <style name="paragraph"> ploplpoplpoplploplpo frudubulubruih :) </style> --------------------------------------

notice the difference between the (ugly) formating tags at the beginning, and the descriptive style tags, wich then define the look of the text.

The ability to expose the internal XML for text objects might also be rather interesting for the Python interface. (ringerc)

The approaches of Inkscape and InDesign are worth looking at. (christoph_s)

Inkscape's re-architecturing effort: Subsystem Architecture

OpenOffice import/export extension for the Story Editor

Text export feature: ODT or other

Start with the OO text import plugin and work out a plugin that would export valid Open Document Format (ODF) xml for re-import into OpenOffice.

Scribus-specific elements and attributes would need to be stripped off, of course.

Multiple Search and Replace

#1105 Search and Replace for the whole document

Allow users to do multiple search/replace action at once in a document. For each string we’d be able to access all settings available right now for just one text string. This will add computing power to Scribus, from the UI.

Individual snappable baseline grid lines

#2899 Snap items to baseline grid

Make an option to make any specific line on that grid snappable through the Guide Manager and show it with a different color.

A snap to guide option is useful when there are few guides. The baseline grid has many lines... It could become annoying to make the entire grid "snappable".

Concepts of main grid, baseline grid, guides, and margins are closely related. Maybe they could be unified into a single general framework. You would have a single general way to create guide lines, either individually or in autospaced groups, the latter either by absolute spacing (like the baseline grid) or by subdivision of an existing space (the way you can with guides). You could define multiple guide sets as styles and apply them to as many pages or frames as you like, and any set could be allowed to be used as baselines for text, column boundaries, page subdivisions, print cropping boundaries (like margins), etc.--not only a single and/or equally spaced special-purpose set for each function. Any set could be set to snap or not independently. What would be really neat is to allow them to be defined relative to each other (equal subdivisions within margins or columns, for instance) and/or to other objects (like bug #3343), and for some or all of these relationships to be able to be made persistent--so changing line spacing could adjust the baseline grid, or vice-versa, and persistently-snapped objects would adjust accordingly, or your four equal subdivisions of a column, along with anything snapped to them, would auto-update if you change the size of the column. Of course persistent snapping would be optional. Some CAD programs have facilities for this kind of thing. This would integrate nicely with a more general idea for relative placement and stylable frame positioning that I had, which I'll post as soon as I finish thinking it through coherently. :)

I think this would help the designer better than having a whole lot of snappable lines everywhere on the page. But we could leave the option of making all the guides snappable as well, whenever needed, to make everyone happy!

Other consideration: I barely never use the small and large grids. But I use all the time the baseline grid and the margins and the columns guides. Mainly because this is really what defines the structure of the pages in publications of many pages, with text and pictures (eg. magazines). Of course, if I were to design posters and stand alone ad pages, I would prefer (maybe) to use the large/small grid. This is to say we might want to make a better integration of the columns/margins guides AND baseline grid on one hand, and the regular grid on the other. I have difficulties considering working with both at the same time. I think they exist for different purposes.

The synchronization of objects with text can be achieved a different way by anchoring objects to text. The objects then follow the paragraph settings or the wordspace, depending on where it is located. The object can also be aligned just like a paragraph. Changes into paragraph formatting make the objects move as well, with the text.

I agree that baseline grid should be set not too far away from the linespacing. Whether change in one should reflects on the other is questionable imo. Considering the fact that there may be lots of various linespaces in a page, which one is THE one?

Great idea to be able to set individual grid lines snappable. This could apply to normal guides too: you might want to define all the guides you need for various aspects of the layout but then on the fly enable or disable specific ones for snapping, depending on what aspect you're working on. If you could define separate sets of guides that you could switch between that would also help.

Maybe another idea could be to snap only when holding down some modifier key, so you can freely position objects except when you specifically want to snap.

This is to say we might want to make a better integration of the columns/margins guides AND baseline grid on one hand, and the regular grid on the other.

Arbitrary user-defined grid/guide sets where you can select at any time which one(s) to use would let everyone use exactly what they want.

Incidentally, a suggestion christoph_s brought up in bug 0002724 to have different guides for different layers could be possible with this scheme--it could be as simple or as intricate as users want.

The synchronization of objects with text can be achieved a different way by anchoring objects to text.

Right, like we can do to some extent now with inline frames. But snapping to a baseline would provide a different possibility, anchoring an object to a line in a text frame, regardless of what text is actually there. Both mechanisms are useful.

I agree that baseline grid should be set not too far away from the linespacing. Whether change in one should reflects on the other is questionable imo. Considering the fact that there may be lots of various linespace in a page, which one is THE one?

There are two ways you can define a baseline grid--as a fixed sequence with a set spacing between the lines (like it is now) or with the gridlines actually anchored to the real text baselines. If you change a paragraph's line spacing, the whole grid adjusts accordingly. The point of the second approach would be to allow what I described above, snapping another object to a given line of text in a frame. Again, I think both would be useful.

The general principle is that guides could be independent or defined by/anchored to objects, just like objects could be independent or anchored to guides.

Unclassified

RTF importer
WordPerfect importer

SoC2007 ideas

Contents