Hi,
Recently a Perl extension called "Cut marks" was added to SVN. I must admit I didn't have very good feelings about this, because Windows users who are majority of our user base or at least very close to it will have an extra step of installing ActivePerl to be able to use it. IMO, having several programming languages supported is fine as long as extensions work everywhere out of box. We already have functionality available on one platform and not available on the other and it probably wouldn't be wise pushing this even further.
And now here comes a similar extension written in Python: https://bugs.launchpad.net/inkscape/+bug/301776
I'm not sure both extensions do exactly the same things. But it may be possible to merge the codes in one extension. I'll try to have a discussion with Aurelio (cut marks' writer) in order to find a solution. Before that, your suggestions are welcome! -- Nicolas
2008/11/25 Nicolas Dufour wrote:
I'm not sure both extensions do exactly the same things. But it may be possible to merge the codes in one extension. I'll try to have a discussion with Aurelio (cut marks' writer) in order to find a solution. Before that, your suggestions are welcome!
http://img37.picoodle.com/img/img37/3/11/25/f_scribuspdfm_d785781.png
That's Scribus 1.3.5 :-)
Alexandre
http://img37.picoodle.com/img/img37/3/11/25/f_scribuspdfm_d785781.png
That's Scribus 1.3.5 :-)
Well, ok. I'll try to do that...
Just a question. Is pt the only needed unit? What about other measurements (mm, in, px...)? -- Nicolas
2008/11/25 Nicolas Dufour wrote:
http://img37.picoodle.com/img/img37/3/11/25/f_scribuspdfm_d785781.png
That's Scribus 1.3.5 :-)
Well, ok. I'll try to do that...
You can do it in PDF export dialog? Really? That would be awesome!
Just a question. Is pt the only needed unit? What about other measurements (mm, in, px...)?
In Qt dialogs unit inside a spinbox widget is merely a reminder. Ideally you only need to see it just once when you set up unit in document properties. All other dialogs should operate on that unit automagically. Unfortunately, this is not the case with Inkscape yet.
Alexandre
You can do it in PDF export dialog? Really? That would be awesome!
Did I say that? I'm afraid my coding skills are limited to scripting, markups and CSS... What I can do is have the CropMarks extension look like Scribus' PDF export dialog, and render the marks on the canvas.
-- Nicolas
devel
Alexander,
You read my mind, this is something i've been expecting for very long in Inkscape (along with a CMYK PDF export). Scribus's dialog is IMO the best way to visually represent the functionality, looks a lot like the Indesign and Corel Draw dialogs. And of course the ultimate thing is to have it implemented in the PDF export dialog. Crop, bleed and registration marks are placed on export along with the color bars and page info, they're not very useful on the canvas itself, I generally just draw them by hand if I need some extra crop or bend marks on the canvas itself.
Best regards, Mourad Mokrane Art director Lumen Media s.r.o. www.lumenstudio.net
----- Original Message ----- From: "Alexandre Prokoudine" <alexandre.prokoudine@...400...> To: "Inkscape Devel List" inkscape-devel@lists.sourceforge.net Sent: Tuesday, November 25, 2008 2:48 PM Subject: Re: [Inkscape-devel] Re : Re : cut/crop marks extensions
2008/11/25 Nicolas Dufour wrote:
http://img37.picoodle.com/img/img37/3/11/25/f_scribuspdfm_d785781.png
That's Scribus 1.3.5 :-)
Well, ok. I'll try to do that...
You can do it in PDF export dialog? Really? That would be awesome!
Just a question. Is pt the only needed unit? What about other measurements (mm, in, px...)?
In Qt dialogs unit inside a spinbox widget is merely a reminder. Ideally you only need to see it just once when you set up unit in document properties. All other dialogs should operate on that unit automagically. Unfortunately, this is not the case with Inkscape yet.
Alexandre
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
There is a known issue with these extensions!
One of the possible marks is the alignment mark, a circle with a cross that is meant to guarantee that the color channels are properly aligned when printed. As some of you know, black text should be drawn using only black ink, so it is expected that any automatic convertion from RGB to CMYK to translate black elements into pure black ink. But these alignment marks should be painted in black, but represented by a mix of all inks: cyan, magenta, yellow, black, and possibly spot colors too, I think.
So, here we reached the real issue: if these are drawn on canvas, then there is no automatic cmyk output that will treat black text and drawing elements in a way an then treat black alignment marks diferently. So, this means that these maks should be drawn not by an extension in the document/canvas level, but by core code (in the pdf export code). And then, I agree that this functionality shoul move to the export dialog.
Juca
There is a known issue with these extensions!
One of the possible marks is the alignment mark, a circle with a cross that is meant to guarantee that the color channels are properly aligned when printed.
Ok, I understand. Is there a way (double circle, or another convention?) to design an alignment mark which doesn't need to be printed in pure black ?
And then, I agree that this functionality shoul move to the export dialog.
I have worked on the extension so that it looks like Scribus' s PDF dialog. Bleed marks, crop marks, and registration marks are available, with some options (offset, bleed size). I plan to update my files in launchpad, so that you can see what it looks like. If you give me a clue, I can change the current alignment mark so that it doesn't require pure black. Then, tell me if you think it's a good thing to keep it as a temporary extension, since the funtionality doesn't exists as a PDF export dialog. I don't remember having seen it in the blueprints. We sure should add it.
Thanks for your comments. -- Nicolas
2008/11/25 Nicolas Dufour wrote:
Then, tell me if you think it's a good thing to keep it as a temporary extension, since the funtionality doesn't exists as a PDF export dialog.
I think it definitely is a good idea. It doesn't hurt to have a workaround :-)
Alexandre
Is there a way (double circle, or another convention?) to design an alignment mark which doesn't need to be printed in pure black ?
well... it is the oposite. it is required that these marks are drawn using a combination of all inks... But yeah, maybe we could figure out a way of doing it in a way that do not depend on the specific algorithm used in the color separator... I would say that maybe we could draw a set of parallel lines alternating each of the colors.
better than this... we could draw a series of paths with the shape of a V so that we can detect wrong alignments in all possible directions.( with a simple set of parallel lines one could not noticed when a printing is misaligned in the direction of the lines. the V shapes would avoid this)
I have a drawing attached, tell me what you think
Juca
Hi,
we could draw a series of paths with the shape of a V so that we can detect wrong alignments in all possible directions.( with a simple set of parallel lines one could not noticed when a printing is misaligned in the direction of the lines. the V shapes would avoid this)
I have a drawing attached, tell me what you think
I'm not convinced by the V shape. It really looks too exotic to me. But what about a multi-colored circle (your left drawing) and a cross below it (svg attached)?
-- Nicolas
I am not convinced by your suggestion eighter.
these marks are intended to detect misalignmets. It meas it should be clear when something goes with any of the color components. What could go wrong? One of the channels could have a slight linear offset both horizontal and/or vertical. Or it cold have an angular offset.
all of these errors should be easily detectable in with a certain alignment mark.
On Wed, Nov 26, 2008 at 8:10 AM, Nicolas Dufour <nicoduf@...48...> wrote:
Hi,
we could draw a series of paths with the shape of a V so that we can detect wrong alignments in all possible directions.( with a simple set of parallel lines one could not noticed when a printing is misaligned in the direction of the lines. the V shapes would avoid this)
I have a drawing attached, tell me what you think
I'm not convinced by the V shape. It really looks too exotic to me. But what about a multi-colored circle (your left drawing) and a cross below it (svg attached)?
-- Nicolas
I am not convinced by your suggestion eighter.
And you are right. I really missed the point...
I've updated the files on Launchpad. https://bugs.launchpad.net/inkscape/+bug/301776
Here's what's working now: . Crop Marks (with a default 7mm plus offset); . Bleed Marks (with different top, bottom, left and right margins); . Registration Marks (updated to use V shaped multicolor marks). What's not working yet, but planned: . Page information (date, title...); . Colour bars; . Use the bounding box of the selection to define the size of the extra marks (boolean). The last two are already done in the Cutmarks extension, and Aurélio will merge both extensions in Python (no more ActivePerl!!!).
Thanks for your help and comments. -- Nicolas
On Tue, Nov 25, 2008 at 10:03 AM, Nicolas Dufour <nicoduf@...48...> wrote:
Hi,
Recently a Perl extension called "Cut marks" was added to SVN. I must admit I didn't have very good feelings about this, because Windows users who are majority of our user base or at least very close to it will have an extra step of installing ActivePerl to be able to use it. IMO, having several programming languages supported is fine as long as extensions work everywhere out of box. We already have functionality available on one platform and not available on the other and it probably wouldn't be wise pushing this even further.
And now here comes a similar extension written in Python: https://bugs.launchpad.net/inkscape/+bug/301776
I'm not sure both extensions do exactly the same things. But it may be possible to merge the codes in one extension. I'll try to have a discussion with Aurelio (cut marks' writer) in order to find a solution. Before that, your suggestions are welcome!
Hi Nicolas, this extensions are not equal, but we can join the features in only one extension. I did it in PERL because i like it and Python is more difficult to me (yes i'm a different guy), but we can rewrite in Python.
Aurium
-- Nicolas
participants (5)
-
unknown＠example.com -
Alexandre Prokoudine -
Aurélio A. Heckert -
Felipe Sanches -
Nicolas Dufour