|· Hosting provided by Anduin.net / Øverby Consulting ·|
|Anonymous | Login | Signup for a new account||2014-10-25 17:16 CEST|
|My View | View Issues | Change Log | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000393||Scribus||Graphics / Image Frames||public||2004-04-01 08:46||2006-05-26 23:45|
|Target Version||Fixed in Version|
|Summary||0000393: SVG inside a picture frame|
|Description||please add SVG to the supported formats of picture frames|
Additional description from the duplicate RFE 0003441:
I would like the ability to construct a scribus document which references external SVGs. If the SVG changes, I should be able to print/export-to-PDF the scribus document and get the new version of the .SVG without having to re-import or re-reference the SVG files.
In this case the .SVG should be treated much the same way as a PNG or JPG is within the editor (as an atomic unit).
|Tags||No tags attached.|
Why should we use a Picture Frame here, a SVG can be imported as an ordinary
Scribus Object with Import SVG.. ?
Well, I thought this is obvious. This is very useful for logos, etc.:
-you can scale an image by % of original size
-the image is easy to update in all documents that use it because it is stored in a seperate file
-you can switch the display of an image off, that makes large documents faster and that makes complex images easier to place (take http://scribus.bradney.info/file_download.php?file_id=77&type=bug [^] as an example)
-other vector images (PDF,EPS) are already supported
This is not meant as a replacement for Import SVG, but as an addition.
|bumping to 1.3|
I'm with the submitter on this issue ... I'd be much more comfortable with being able to shove vector graphics formats into a picture frame too (without having to rasterise them). That makes cropping them, shoving them around, etc simpler.
I assume, however, that this bug refers to importing SVG into a picture frame as a raster image (like we do with EPS and PDF).
from my comments on the mailing list:
Scribus being essentially a frame-based tool, we should stay accustomed to first drawing a frame and then filling it with something (consistency is good.) The possible exception to this would be the built-in graphic primitives. Scribus is a layout application and not a graphics tool. IMO, that duty really should be entirely outsourced to more capable tools such as InkScape and GIMP. From there, we can import them into a graphic frame.
I see no reason why we cannot have frame types of 'text,' 'graphic:raster' and 'graphic:vector' rather than the current 'text' and 'graphic:raster.'
>>>Scribus being essentially a frame-based tool, we should stay accustomed to first drawing a frame and then filling it with something (consistency is good.) The possible exception to this would be the built-in graphic primitives. Scribus is a layout application and not a graphics tool. IMO, that duty really should be entirely outsourced to more capable tools such as InkScape and GIMP. From there, we can import them into a graphic frame.
As you mentioned, some *basic* drawing tools as they exist by now are very useful, and, I might add, some basic tools for image manipulation as introduced with 1.3 are useful as well. There's no need for some kind of "outsourcing", IMHO, especially if you think about the opportunity to start your favourite image manipulation programme from within scribus.
>>>I see no reason why we cannot have frame types of 'text,' 'graphic:raster' and 'graphic:vector' rather than the current 'text' and 'graphic:raster
Since PDF, PS and EPS are no bitmap formats, I think one kind of frame for all kinds of graphics files would be sufficient. Don't confuse the users more than necessary ;)
You also have to keep in mind that once other OpenOffice.org files (tables, presentations) can be imported, as per the road map, probably another kind of frame will come into play. And on the roadmap, we also read of formulas (LaTeX, MathML), wich would be the next special purpose frame ...
Planned in Roadmap Extras http://wiki.scribus.net/index.php/1.3.x_Roadmap_Extras [^]
with no ETA
Changing the status to acknowledged
There have also been hints floating around for a while of discussions about supporting references to pages or other frames in a frame, like with the imposition stuff. And with the ability to include parts of other scribus documents in the current document, the difference between referencing internal objects and objects in external files--which is what image frames do--is lessened. Might the image frame simply be converted into a general "include something else and place it here with a few options" frame?
The something else could be an external (raster or vector) image type, a page from the current or another document, or any group of frames, and the options as now would include resize, position in frame, crop, apply a border, and turn off display for performance.
That way, an SVG or any scribus native primitives could be imported and edited natively in scribus if desired and still placed in a frame for easy manipulation without affecting the source object(s).
Notes from bug 0003441 which was closed as duplicate:
Hm, I'm having seconds thought about importing SVG automatically from external files. What should Scribus do if the drawing was edited in Scribus??
I'd rather add an option to imageframes to load SVG, and make sure that SVG, EPS and PDF are *not* rastered when Scribubs creates PS or PDF. AFAIK this only works for EPS and printing at the moment.
<quote>What should Scribus do if the drawing was edited in Scribus??</quote>
I think the whole idea of this request is that it shouldn't be edited in Scribus, just referenced. I can imagine, the request author would like to edit his SVG's in an vector drawing application which offers superior editing capabilities which are not available in Scribus. Scribus should only produce a placeholding preview and launch his external editor, if he wants to edit it (just the way it works with gimp-remote -- yet another setting in Preferences would be needed). Furtherly, it probably means, SVG's in image frames shouldn't be handled as Scribus native objects, contrarily to the imported SVG's, which should be available as well.
<quoting>I'd rather add an option to imageframes to load SVG, and make sure that SVG, EPS and PDF are *not* rastered when Scribubs creates PS or PDF. AFAIK this only works for EPS and printing at the moment.</quoting>
This doesn't contradict having the SVG's as external, referenced files in image frames. The abovementioned steps would be performed while printing/exporting to PDF/PS and are more than necessary anyway, imho.
Same goes for EPS, we really need to be able to have vector illustrations as images, and that includes text.
|For the record, the SVGs I am interested are at http://www.purplefrog.com/~thoth/guitar-hero/ [^] . They are generated by software, and when I make an enhancement to my SVG-generating tool I re-generate all 192 .SVG files. I really would not want to have to re-create a Scribus document which includes them. I am holding off on a "book" version of that site until I find software which makes updates pain-free enough.|
|2004-04-01 08:46||hhielscher||New Issue|
|2004-04-02 00:31||fschmid||Note Added: 0000881|
|2004-04-02 01:31||hhielscher||Note Added: 0000882|
|2005-04-16 15:32||plinnell||Note Added: 0004271|
|2005-04-16 15:32||plinnell||Product Version||1.1.6 => 1.3|
|2005-04-19 11:20||ringerc||Note Added: 0004286|
|2005-08-03 23:04||paraplegic_racehorse||Note Added: 0005879|
|2005-08-03 23:19||christoph_s||Note Added: 0005880|
|2006-04-13 21:13||mhanski||Note Added: 0009908|
|2006-04-13 21:13||mhanski||Status||new => acknowledged|
|2006-04-13 22:11||mkoren||Note Added: 0009916|
|2006-04-30 00:29||mhanski||Relationship added||related to 0003441|
|2006-04-30 20:54||cbradney||Relationship replaced||has duplicate 0003441|
|2006-04-30 21:16||mhanski||Description Updated|
|2006-04-30 21:24||mhanski||Note Added: 0010709|
|2006-04-30 21:25||mhanski||Note Added: 0010710|
|2006-04-30 21:26||mhanski||Note Deleted: 0010710|
|2006-04-30 21:29||mhanski||Description Updated|
|2006-05-01 21:20||thoth||Note Added: 0010743|
|2006-05-17 20:37||christoph_s||Relationship added||child of 0002931|
|2006-05-26 23:43||mhanski||Relationship added||related to 0003863|
|2006-05-26 23:45||mhanski||Relationship added||related to 0003783|
|2009-11-15 04:16||jghali||Relationship added||has duplicate 0008534|
|2011-10-09 23:22||jghali||Relationship added||has duplicate 0010309|
|My View | View Issues | Change Log | Roadmap | Repositories|
|Copyright © 2000 - 2014 MantisBT Team|