SoC2007 ideas: Difference between revisions

From Scribus Wiki
Jump to navigation Jump to search
Line 76: Line 76:


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.
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 ===
*[http://bugs.scribus.net/view.php?id=2899 #2899 Snap items to baseline grid]
think baseline snapping is a good idea, so objects can be synchronized with text.
kavs0007, in the mean time, you could also make your own guides (the blue ones), with the manage guides tool on the page menu. You can have as many as you want automatically generated and apply them to all pages if you want them to act like the baseline grid.
This brings up a good point: all these concepts--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 individaully 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. :)


=== Unclassified ===
=== Unclassified ===


*[http://bugs.scribus.net/view.php?id=2899 Snap items to baseline grid]
 
*[http://bugs.scribus.net/view.php?id=3343 Snap guides to items]
*[http://bugs.scribus.net/view.php?id=3343 Snap guides to items]
*[http://bugs.scribus.net/view.php?id=128 TeX rendering engine]
*[http://bugs.scribus.net/view.php?id=128 TeX rendering engine]

Revision as of 18:19, 16 March 2007

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

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

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

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

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

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

think baseline snapping is a good idea, so objects can be synchronized with text. kavs0007, in the mean time, you could also make your own guides (the blue ones), with the manage guides tool on the page menu. You can have as many as you want automatically generated and apply them to all pages if you want them to act like the baseline grid. This brings up a good point: all these concepts--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 individaully 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. :)

Unclassified

  • RTF importer
  • WordPerfect importer