Print PDF Output

[wwderw]

Ideally, would like to have an option within the Embroider module that allows for ticking a box (which activates sub options, 1 for approval sheet (Realistic Rendering of the design) and 2nd for the color blocks of the design (the colors used might actually be easier to do, if it is pulled from the layer names, of course, that would mean that the layers would have to be named as colors for that to work). Size and stitch count would also be nice to have on the approval sheet.

See attached PDF that is generated within Wilcom's TruSizer program.

EmbroiderModder has some basic functionality of this with their print to PDF (see attached for that one, I did remove the grid and ruler from the printout). It does allow for realistic rendering.

One workaround to this issue that I can think of, which wouldn't affect InkStitch, is to bring the CSV file into embroidermodder, get that image. Then get the individual layers from Inkscape and plug those into a Scribus template and then do a Print to PDF from there. Printout Samples.zip

[lexelby]

I love the idea! Especially the color blocks. I believe some (maybe all?) embroidery thread manufacturers provide a list of RGB -> thread color. Ink/stitch could fairly easily use the colors assigned to objects in the SVG and match to the nearest thread color to get the name.

Generation of PDFs for each layer is super-simple. Inkscape has command-line arguments for exporting an SVG to a PDF, designed specifically with the idea that extensions could write out an SVG and run inkscape in the background to do this kind of exporting. Ink/stitch can write out multiple copies of the SVG and convert in this way, each with one color in turn.

There's really no need to separate the colors by layer, since ink/stitch already has the ability to track color changes from one object to the next. Of course, you can arrange your colors into layers if that suits you :)

What's going to be tricky is realistic rendering. I'm going to have to do some thinking on that, and I'm pretty sure it's not going to be a short-term feature. There are patents for that kind of thing too, so I'll have to avoid violating them(!).

One technique that may work is to get a thread-like appearance using some of Inkscape's filters. If you can produce threads like that in an SVG in Inkscape, then I may be able to build on that to generate a realistic rendering of a design as an SVG, at which point I can just export to PDF like above.

But it really depends on whether the filters will do what you want. Getting the kind of lighting/shading of a satin like in your Wilcom example may require some kind of 3D rendering, which is something I have zero experience with.

So, great idea, but I may not be skilled enough to implement it. Maybe someone with 3d rendering experience might jump in here? :)

[wwderw]

I love the idea! Especially the color blocks. I believe some (maybe all?) embroidery thread manufacturers provide a list of RGB -> thread color. Ink/stitch could fairly easily use the colors assigned to objects in the SVG and match to the nearest thread color to get the name.

Some do have RGB to their thread color (Brother threads for sure). I just didn't know how easy it would be to incorporate that with the print out. If it isn't that bad, that would be great to be able to do.

Now this:

Generation of PDFs for each layer is super-simple. Inkscape has command-line arguments for exporting an SVG to a PDF, designed specifically with the idea that extensions could write out an SVG and run inkscape in the background to do this kind of exporting. Ink/stitch can write out multiple copies of the SVG and convert in this way, each with one color in turn.

and this:

There's really no need to separate the colors by layer, since ink/stitch already has the ability to track color changes from one object to the next. Of course, you can arrange your colors into layers if that suits you :)

Is really due to my ignorance. While I am a heavy layers user, I was thinking that doing it this way would also make it easier to implement this function.

I would probably still do it (and for my test project and doing things like White - Eyes and Shirt).

I have to test things out by having projects, it's how I learn to do things, it forces me to use certain features for certain objects.

If we do get snowed in starting tomorrow and over the weekend, I might be able to get it done, I'm doing this one on my spare time, I'll post a pic of the Embroidery layer when I'm done.

What's going to be tricky is realistic rendering. I'm going to have to do some thinking on that, and I'm pretty sure it's not going to be a short-term feature. There are patents for that kind of thing too, so I'll have to avoid violating them(!).

I would say at this point, stick with how the embroidery layer does it right now and bring that simulation in to the PDF.

[lexelby]

I would probably still do it (and for my test project and doing things like White - Eyes and Shirt).

Ah, this is a really good point, the ability to name each section. I'll have to think on that... maybe using the layer name is the way to go. Hmm.

I would say at this point, stick with how the embroidery layer does it right now and bring that simulation in to the PDF.

Got it, shouldn't be too hard, and I like the idea of getting something working first before trying to tackle something harder like realistic rendering.

[wwderw]

It's too bad we couldn't leverage embroidermodder's simulated view. It's not bad.

A little bit the project I'm doing to give the extension a good test run.

[lexelby]

It's too bad we couldn't leverage embroidermodder's simulated view. It's not bad.

Now there's an idea. I'm going to have to give that some serious thought. It's actually not completely out of the question.

A little bit the project I'm doing to give the extension a good test run.

Neat! Looking forward to seeing what you come up with :)

[wwderw]

I love the idea! Especially the color blocks. I believe some (maybe all?) embroidery thread manufacturers provide a list of RGB -> thread color. Ink/stitch could fairly easily use the colors assigned to objects in the SVG and match to the nearest thread color to get the name.

I do have a couple of physical thread palettes (one from Hemingworth, the other from Marathon), I was thinking about creating a gpl palette for Inkscape to use for each of those 2 charts.

My question would be this, it appears to me that the XML data in Inkscape takes the HTML reference of the color not the actual name. When exporting the PDF or however we are exporting the stitching order, is there anyway to take that HTML reference and convert it back to the Name and/or Thread Number? The HTML reference is not going to be relevant to a lot of people.

Or is actually coming up with this palette even worth it for the purposes of this extension?

[lexelby]

Per #19, it would be useful to (optionally?) include the total stitch count and the stitch count for each color change.

[X3msnake]

Yes

2018-01-27 18:26 GMT+00:00 Lex Neva notifications@github.com:

Per #19 https://github.com/lexelby/inkstitch/issues/19, it would be useful to (optionally?) include the total stitch count and the stitch count for each color change.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lexelby/inkstitch/issues/18#issuecomment-361004693, or mute the thread https://github.com/notifications/unsubscribe-auth/AKke-ljtGqpKoWPKdD3qqNv_bo5adknFks5tO2pJgaJpZM4RbWNa .

-- Com os melhores cumprimentos, Vinicius Silva

[lexelby]

I'm starting to tinker around with this. My original plan, as described above, was for inkstitch to invoke inkscape itself to do the rendering in the background. Inkscape has a command-line interface for exactly this purpose.

The problem is that Inkscape doesn't (as far as I can tell) inform the extension of where to find the Inkscape executable. I don't really like the idea of ink/stitch trying to figure out where Inkscape is installed in order to run it.

My current plan is for ink/stitch to "render" the printout to HTML and open it in the user's web browser. This has a few distinct advantages:

• there's a python module to invoke the user's preferred web browser in a cross-platform-compatible manner
• HTML files can include entire(!) SVG documents inline directly, as if <svg> were a normal HTML tag
• all of the major browsers support SVG filter effects
  • this means that, once we find a satisfying filter effect for realistic rendering, the PDF printout feature can use it easily
• CSS allows us to specify styling rules that apply to the screen and printout separately
  • this lets us show a sort of "print preview" view in the browser, printing instructions, and a "print" button
• If the user desires a PDF rather than a hard copy, they can use their OS's "print to pdf" feature.

I"m going to use jinja2 as a template engine. ink/stitch will generate the SVG chunks for each color block, the full preview, and the color change list ("production summary" in the wilcom example PDF). Then it will process the jinja2 template which will assemble the SVG chunks and other information like thread counts, color names, etc into an HTML file.

@wwderw @AkiraNorthstar @X3msnake Is any of you by any chance proficient with HTML/CSS? I can do it no problem if not, but I'm definitely not a wonderful web designer. It'd be cool if we could collaborate on this one.

[X3msnake]

@lexelby I'm ok with web design where can i help?

[lexelby]

Great! As a start, you could mock up an output along the lines of the Wilcom example @wwderw included in the original post above. Just use grey boxes as placeholders for SVGs. I can turn it into a jinja2 template later on.

Let's try not to follow Wilcom's design too closely just so they won't have any reason to be upset with us. You could perhaps add a placeholder for the ink/stitch logo at the bottom of the last page or something... :)

Here's the little bit I tried out so far just to see how things work:

<html>
<head>
<style>
@media all {
    svg {
        display: block;
    }
}

@media screen {
    svg {
        border: 1px solid black;
        page-break-after: always;
        margin-bottom: 20px;
    }
}

@media print {
    svg {
        page-break-after: always;
    }
}

</style>
</head>
<body>
[SVG here]
[another SVG here]
</body>
</html>

Feel free to take this or leave it. Mostly I just thought I'd share the @media stuff.

[X3msnake]

cool

if you don't mind i will do some mockups in corel first and post them here for us to see if it look right as we want it, from there it is quite easy to setup the htm/css ;)

Ideally i think we should try having all this in one page only and not multiple pages like wilcom

heres's what i got

gfx = graphic

• Branding- inkStitch Logo (gfx)
• Info - The file title
• Info - The page date
• Info - total stitch count
• Info - total thread used
• Info - number of colours used
• Info - stitchout dimensions xy
• Info - stitchout scale
• Info - page number
• Info - number of pages
• Simulation - The stitching simulation (gfx)
• Colours used - name
• Colours used - swatch (gfx)
• Colours used - stitch count for colour
• Colours used - thread used for colour

@wwderw can you add or remove to this list the info/gfx that would be perfect to have on the PDFs?

[wwderw]

@lexelby I do have a small amount of HTML chops. Dated as far as websites go, but still may be usable (or I just know enough to cause damage, who knows with me) for tweaking.

@X3msnake

For Branding, I would say both branding of the extension and the branding of the individual if using this for commercial use.

For Info: Title, Date File Created, Total Stitch Count, Number of Colors, Dimensions

Stitching Simulation: I would also include scale with this. 1:1 for things that can fit the normal page printout. Zoom to fit for anything bigger ("fullback" size). This would probably mean looking at minimum 2 pages. 1 for the simulated design and the other page for the design info. Some info may appear on both pages.

Colors Used: I would also include spool # as well in case that is also supplied.

I would like the chart to recognize when a stop command is used, maybe when sequin commands are used as well, if we are able to implement that functionality, but since we have stop commands, I think for sure it should recognize those, so people know what that extra color change function is for.

Also on individual elements, be able to say 60 weight use here, 40 weight used here. Suggested speed in this section etc. I don't know if we are able to get that individualized or not, but I think have notes would be good as well. Better if they can be put exactly at the color block used, maybe a text box in the HTML next to the color blocks that can be edited in the browser before "printed"?

This is at least what my mind is able to come up with this early in the morning. I may be able to think of more later on.

[lexelby]

An editable text box in the html is doable. But is it going to be annoying to have to add the text again every time you print a given design?

[wwderw]

I would print to PDF once that is finalized. I rarely physically print anything out. Certainly when I send designs out, but my office computer and the computer out in the shop share a NAS, so I just pull it up there when I'm at the machine.

The one time that it may become an issue, is if I had to change the design physically that would cause me to "print" a new printout.

I'm pretty sure we could add notes in more of a "global" way via Inkscape, but I don't know if we are able to "localize" it to specific color blocks. But if in the end, it's better to do that, it'll work as well.

[lexelby]

Actually, we may be able to have the best of both worlds here. Instead of popping up a browser, I can use a "webview" which will be a captive browser in inkstitch itself. I could make it so that user can enter text and it would get saved back into the SVG for next time.

In fact, this may be the best way to handle color naming. What if you could select and/or enter thread colors right on the color block page just before printing or saving to PDF, and inkstitch remembered what you entered?

[wwderw]

That'll be better.

I can see, especially the color, if there is a need for specialty thread (glow in the dark, metallic etc) that isn't usually found within a normal thread palette, easier to input that info and have it saved as well.

What the default be populated with what was used in the design originally and then just editable right before "printing"?

[lexelby]

I'm thinking there won't be a way to enter the color/thread names at all aside from the print preview screen. But default, it would try to pick a thread color that matches the RGB value of the objects in the SVG as closely as possible. If you have a thread-set loaded as a color palette and use colors from that, then the RGB value would match exactly and it would know which thread you want.

[X3msnake]

If you use the colour palletes @AkiraNorthstar did, it is named on the colour swatch, @lexelby you can probably fetch that colour swatch and pallete name no?

[lexelby]

Ooh, I bet I could!

[wwderw]

If you have a thread-set loaded as a color palette and use colors from that, then the RGB value would match exactly and it would know which thread you want.

I have created some thread palettes (the 5 palettes that I use in work) so the RGB values would be a match.

Would there be a way to populate with the palette colors from this info?

or would it only pull the RGB or HTML (from the XML Editor)?

If we can pull from how it's labeled in the palette, I think that would be best for default population and then edit it as the user sees fit later on.

[lexelby]

Yup, I think you two just described the same thing, probably typing simultaneously. I think it is possible to pull the info out of the palette and that sounds like the best way to do it.

[X3msnake]

Awsome

I started working on a template I will try to upload the ideas here when i get home from work. :)

[X3msnake]

inkStitch_PDF_Template.pdf

[X3msnake]

@wwderw @lexelby @AkiraNorthstar here's a first mockup of what the pdf might look, tell me what you think

[lexelby]

Ooh, shiny! I'm not sure what the color sections at the bottom refer to, but there's one thing I want to bring up: let's ensure that this is accessible for color-blind folks. We can't depend on someone's ability to see a color in the top section and cross-reference it below.

[X3msnake]

The colors in the bottom are placeholders for up to 12 colours in the same design

This is the single page view. If the user wants he can check a box a get the detiled view wich is similar but generates a page per colour.

No dia segunda-feira, 5 de março de 2018, Lex Neva notifications@github.com escreveu:

Ooh, shiny! I'm not sure what the color sections at the bottom refer to, but there's one thing I want to bring up: let's ensure that this is accessible for color-blind folks. We can't depend on someone's ability to see a color in the top section and cross-reference it below.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lexelby/inkstitch/issues/18#issuecomment-370582740, or mute the thread https://github.com/notifications/unsubscribe-auth/AKke-nyl3HjwBxuMb32kUZG0lg84Q7Asks5tbbW9gaJpZM4RbWNa .

-- Com os melhores cumprimentos, Vinicius Silva

[wwderw]

Niiicceee.

I'm wondering, should we have areas for a PO area and/or approval siggys from the client?

Should we also include lower thread usage or is thread used include both upper and lower?

The colors, sometimes I'll go over 12 colors in a single design either due to sequencing (especially realistic embroidery) or there will be more then 12 unique colors, this will populate to another page beyond 12 correct?

The expanded view, will that also get a preview of the simulated embroidery color block as well with the color swatch? They may also help with just not only color blind people being able to say this block for this area in the design. Sometimes it's not easy for anyone.

Will there be a way to get both at one time or one or the other?

[lexelby]

Perhaps a checkbox on each page, "include this page in print-out". That's something I could pretty easily code. That way if they don't need a PO and approval page, they can disable those.

[wwderw]

@lexelby

I would say that's perfect. I don't need those all the time either, so that would be a nice option to have.

[X3msnake]

@wwderw @lexelby

this is how i see the colour swatches updating on the main page up to 48 colours, we can get up to 96 in the same page and only display the stitch count

The first page is always rendered, it is the main page where you see the full design and a overview of the total project.

If the user wants he can also ask the extension to do a detailed version that would display the block color and the one swatch the block represent like on the one colour only display

[lexelby]

I see what you're going for with that, but it's going to be pretty tricky to code. There'd have to be some kind of fancy CSS and Javascript to distribute the rows of color swatches differently based on how many there are.

[X3msnake]

@lexelby not really, it's simple CSS

I can handle the Css for this no worries ;)

[lexelby]

Awesome! That's way beyond my level :)

[X3msnake]

@lexelby @wwderw @AkiraNorthstar

here´s a simulation of what the print would look with the detailed print selected

[wwderw]

I'm liking that.

[wwderw]

Sorry bout that. On cell phone. Mobile view muugh.

[X3msnake]

@wwderw would you add/remove/change anything?

@lexelby @wwderw @AkiraNorthstar if you guys think this is good enough for a first release the i'll start working on th CSS for the print :)

[wwderw]

@wwderw would you add/remove/change anything?

How would scale work for say a full back or something that wouldn't be 1:1 in the provided area? Would it zoom to fit, so it would say .76 instead of 1:1 (just as an example)?

Is that going to be a static mm/s setting or is that changeable? What is also the conversion for that? I'm used to spm, but if I know a conversion, I can hang.

I'm liking what I'm seeing, I'm thinking it's close to start implementing myself.

[lexelby]

I like what I'm seeing as well. It's polished, simple, clean, and it looks to be relatively easy to implement. It's also distinctly ours, not just a copy of Wilcom's. Actually, I think it looks quite a bit better than Wilcom's ;)

I'm in the midst of working on my side of things. We'll meet in the middle. :)

[X3msnake]

How would scale work for say a full back or something that wouldn't be 1:1 in the provided area? Would it zoom to fit, so it would say .76 instead of 1:1 (just as an example)?

I was thinking relational numbers like in the normal scale 2:1 - 1:1 - 1:2 or we could just swap it for percentage where 100% would be 1:1 200% would be twice the size and 50% would be half the real size

Is that going to be a static mm/s setting or is that changeable? What is also the conversion for that? I'm used to spm, but if I know a conversion, I can hang.

I used what i know sorry it's the CNC habbit. it should be spm as you said

I'm liking what I'm seeing, I'm thinking it's close to start implementing myself.

?

[wwderw]

I'm liking what I'm seeing, I'm thinking it's close to start implementing myself.

?

Good to go.

normal scale 2:1 - 1:1 - 1:2

This will work.

[X3msnake]

Ah ok :D

Gonna start building the CSS

[X3msnake]

@wwderw @lexelby @AkiraNorthstar

here's a first try at the color swatches logic using css3, the jquery there is just to add and remove swatches. the horizontal scale can be solved like that, the vertical i have to work on it...

https://codepen.io/X3msnake/pen/oErZMG

[AkiraNorthstar]

That's nice! do you plan to implement the thread Manufacturer? I know, this is a draft! ;-)

[X3msnake]

@AkiraNorthstar what do you mean?

[wwderw]

Would it also list thread company as well from the palette is what I think is being asked.

Something like: Hemingworth - Classic Black # 1000 (I'm guessing the number, not at the computer to confirm).

[wwderw]

https://codepen.io/X3msnake/pen/oErZMG

I like it.

[AkiraNorthstar]

Something like: Hemingworth - Classic Black # 1000

@X3msnake: Yes, that's what I meant to say.

[X3msnake]

I think it can, as long as it is the name of the palette you are using.

The thing here is since we have the option to see a detailed view, we must choose the hierarchy of importance of each element,

By that i mean wich elements can be made invisible if we run out of space. best yet, what is the most important?

For me the priority would be

---

• Color swatch
  • Color stitch count
  • Color name or number reference / rgb when name not available
    • Color palette company name ( only if pallete is not a generic rgb)

    • Color stops & trims

What is your point of view @lexelby @wwderw @AkiraNorthstar