[Wishlist] [Win32] Support improvements to the print_win32_vector extension

Bug #1729805 reported by AMcBain on 2017-11-03
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Wishlist
AMcBain

Bug Description

Inkscape: .92.2
OS: Windows 10 Home

It's been noted in various tickets (such as issue #1662531 ) the Print Win32 Vector extension is pretty lacking in support for the features available in SVG. I have updated its level of support. Attached to this ticket are the updated py and inx files for the extension.

Originally supported:
- <path>
- <rect> (ignored rx and ry)
- viewBox scaling (latest .92.x source only)
- printing to the system's default printer

Original problems:
- everything was printed with a stroke
- stroke was not scaled according to the current transform
- strokes must have a near-zero width in printer units to be treated as vector lines
- CSS display: none; was only respected on <g> tags
- allowed printing empty documents or documents for which no tags were printed
- document names did not show up on the target device

Support added:
- <rect> with rx and ry
- <circle>
- <ellipse>
- <line>
- <polyline>
- <polygon>
- <text>*
- <flowRoot>*
- CSS stroke-linecap
- CSS stroke-linejoin
- CSS stroke-miterlimit
- CSS fill-rule
- "job type" selector to print only

Support changed:
- only tags with a stroke get printed with a stroke
- stroke is now scaled based on the current transform
- users can choose the maximum stroke width threshold for triggering output of vector lines
- CSS display: none; is respected on any supported element
- empty documents now print a single "do nothing" instruction (as otherwise they hung my Epilog!)
- document names are now properly sent across and displayed

I did port the viewBox scaling changes from the latest repository version, but that's not really a support change or addition as it would have been released with the next version to have the fix.

* These are handled by Inkscape (see following paragraph)

This bug is kind of related to issue #843260 as handling of text requires I launch a new version of Inkscape to convert them, close it, then read back in the changed document. This causes a flash of an Inkscape window (as noted in the aforementioned ticket and elsewhere) which I would be keen to avoid. I already reduce the chance of this by checking if I have any text to convert first, which also likely saves some time printing a document.

Testing:

All parts have been tested by me with my 60W Epilog Mini 24. Tina Tenbergen (ttenbergen) tested the code up to revision 4f5f2ee6eda804b434675672037bdff6f5ca77d9 with one of her makerspace's Epilogs and their Universal brand machine. Results were consistent with mine.

Repository:

https://bitbucket.org/AMcBain/print-win32-vector-plus
This includes a test SVG with everything but text tags in it (though this has been tested separately) and a reference JPG showing the intended output on a laser cutter. The good news is, however, for those who don't have one you can still try it with your laserjet. ;)

Backstory:

I help provide a laser cutting resource in the form of an 60W Epilog Mini 24 to a makerspace and at least one person there would like to be able to use Inkscape instead of CorelDRAW due to familiarity and as their designs originate in Inkscape as well. As I also use Inkscape for many designs I happened to find the Print Win32 Extension offered better vectorizing on Windows and decided to tackle the lack of support for many SVG particulars.

AMcBain (mcbain-asm) wrote :
AMcBain (mcbain-asm) wrote :

I forgot to finish a line above. '- "job type" selector to print only' should read:

- "job type" selector to print only vectors, rasters, or both

This also allowed me to add back in compatibility with the original extension's behavior of adding strokes to items that didn't have any by way of a separate job type. This "compatibility mode" benefits from the newer text, tag, and CSS support I added. (It seemed like too much work and too cruel to do otherwise.)

Mc (mc...) wrote :

Mh, it's arcane windows python code to me, I'm subscribing Alvin to this bug so that he could take a look at it if possible since he wrote the original code:

https://gitlab.com/inkscape/inkscape/merge_requests/111/diffs

Changed in inkscape:
status: New → In Progress
importance: Undecided → Wishlist
assignee: nobody → AMcBain (mcbain-asm)
milestone: none → 0.92.3
Alvin Penner (apenner) wrote :

I tested this code on Windows 10, Inkscape 0.92.2 (5c3e80d, 2017-08-06)

unfortunately, I was not able to get it to print anything. I got the configuration windows for General Settings, used the default options (Combined), click on Apply, get a temporary popup window with no visible text, and no output. I had previously run the original Vector Print code to confirm that it was working normally.

Are there additional operating instructions for using this extension?

AMcBain (mcbain-asm) wrote :

That's odd. There's no other instructions I know of.

The temporary blank window is something I also get. I don't know how to make it to away. I think it turns into the debug output window if your script uses inkex.debug() or exit('string here').

Does the blank window hang around and you get a second window indicating the extension is still processing? It pops up a system print dialog and that could indicate it is behind some windows instead.

If the blank window closes shortly after opening with no debug output that seems to indicate a script crash death.

Just for full info did the script you tested have any text objects in it?

AMcBain (mcbain-asm) wrote :

Also your reported version of Inkscape is the same version I tested on at home and likely the same version I used when testing with my laser cutter. So I would guess this is an environment issue.

Alvin Penner (apenner) wrote :

- it happens with any file, even if I just draw a single line and try to print it.
- happens regardless of the settings in the "General Settings" panel
- I just get that single window, very quickly, no other windows and no printer dialog

AMcBain (mcbain-asm) wrote :

I'll check my copy again this evening, but in the mean time there is something simple you could try:

1. Create shape
2. Run extension with default settings
3. Alt+tab to another app
4. Alt+Tab back to Inkscape

If there's windows hidden underneath things this should bring them to the front (at least on my machines), but only if the extension is "hung" with the mystery blank rectangular window open.

Alvin Penner (apenner) wrote :

I do not see any hidden windows anywhere.

appears to be a security issue. I ran the new code on Windows XP, 0.92.x branch,
version inkscape-0.92.x-b2fd37fc

and get the Python error message:

Traceback (most recent call last):
File "print_win32_vector.py", line 710, in <module> e.affect() File "C:\inkscape-0.92.x-b2fd37fc\build\inkscape\share\extensions\inkex.py", line 283, in affect self.effect()
File "print_win32_vector.py", line 602, in effect if not mycomdlg.PrintDlgA(printdlg):WindowsError: exception: access violation reading 0x00000044

AMcBain (mcbain-asm) wrote :

That seems like a buffer read-after-end. I may need to recheck the fields on the DEVMODE struct I use to see if one of the sets of fields I added is valid for XP. However I think the even the newer fields were added before XP.

I might be able to see if I can boot my XP VM I have around somewhere on my home desktop to test there.

Alvin Penner (apenner) wrote :

the problem does not appear to be related to XP. Just for curiosity, I ran this from DOS, in Windows 10, and got the output:

C:\Program Files (x86)\Inkscape\share\extensions>print_win32_vector.py \windows\temp\ufon.svg
Traceback (most recent call last):
  File "C:\Program Files (x86)\Inkscape\share\extensions\print_win32_vector.py", line 710, in <module>
    e.affect()
  File "C:\Program Files (x86)\Inkscape\share\extensions\inkex.py", line 283, in affect
    self.effect()
  File "C:\Program Files (x86)\Inkscape\share\extensions\print_win32_vector.py", line 602, in effect
    if not mycomdlg.PrintDlgA(printdlg):
WindowsError: exception: access violation reading 0x00000044

AMcBain (mcbain-asm) wrote :

I get the print dialog to appear on my Windows 7 box, so I'll have to head down to my Windows 10 laser cutter PC (it's not at home) and see if I get different results. If it works there, then I can try switching from PrintDlgA to the newer PrintDlgExA function* and see if it works better for you. Otherwise if it exhibits the issue you report I may be able to fix my call to PrintDlgA. Unfortunately my weekend is pretty full, so it might be Monday before I can get that checked.

* This still requires a DEVMODE instance which describes a struct containing an anonymous union of structs. (Very yucky!) However I wasn't able to get the document name across to the laser cutter without trying to be proper here.

I'll attach the updated version of the extension to try to this ticket when I've got something.

Patrick Storz (ede123) on 2017-11-07
tags: added: extensions-plugins
AMcBain (mcbain-asm) wrote :

It worked on my Windows 10 box, so I started in on PrintDlgEx(A) but so far it doesn't want to work. Just tells me I'm giving it some argument that it doesn't like. I'll keep plugging away though.

I still don't know why it would work here on my two test machines and not yours. :-/ Must be something different. (and it may not have to do with Inkscape) If we had a few more testers it might help narrow that down to fix it.

Patrick Storz (ede123) wrote :

I don't have any experience with calling WinAPI from Python, so I can't really help you there, but two ideas which might help debugging:
- Have you considered differences between 32-bit/64-bit builds?
  Not sure if this is a thing in Python but maybe some field in one of
  the structs changes size and needs to be defined differently?
- I read somewhere (and it sounds convincing) that
  "access violation reading 0x00000044"
  might indicate we're trying to access a field of a struct
  which points to NULL (i.e. 44 bytes offset from NULL)

Patrick Storz (ede123) wrote :

A third idea (not sure if it applies here either):
Might there be a Unicode vs ANSI issue (i.e. do you maybe pass an UTF8 string somewhere that is supposed to be an ANSI string which typically messes up character counts and results in strange errors?)

AMcBain (mcbain-asm) wrote :

I don't think so on the Unicode front, as this is Python 2.7 so I'd have to do u"stuff here" to explicitly get Unicode but I can go check just to be sure. I don't recall off the top of my head passing in any string values. Mostly reading ones the come out of the API.

Interesting point on the 0x00...44; I'll look again for things that might be null but shouldn't be.

As to the 32/64 difference, I thought about that but I calculate the size of the struct when I pass it in (it's a required field on one of the structs I must use) on the fly so it will always be the right value. Also I think there might be issues with Python 2.7 32-bit loading 64-bit Windows DLLs, but it may have just been that my Windows 10 box already had Python installed on the path and there was a bit difference between it and the packaged Inkscape Python. I had to get that resolved before I even started in on the first extension changes. Inkscape 64-bit edition seemed to come with a baked in 32-bit Python 2.7, much to my surprise.

AMcBain (mcbain-asm) wrote :

Though now getting what you're saying, if Python 32-bit is able to interface with the Windows 10 64-bit DLLs without barfing, then that would be a restcase to try. Especially in light of my previous comments that I thought I recalled 64-bit Inkscape shipping with 32-bit Python. I'll see about trying the extension in a 32-bit Python on my Windows 10 box outside of Inkscape.

AMcBain (mcbain-asm) wrote :

testcase*

Alvin Penner (apenner) wrote :

>> (and it may not have to do with Inkscape)

yes, I agree, this is not related to Inkscape in any way. I get this error running Python from DOS, without using Inkscape.

just for curiosity, which dialog box are you attempting to load, could you attach a screenshot of what it looks like?

AMcBain (mcbain-asm) wrote :

This is the dialog I'm launching, snapped from my Windows 7 box at home. There's two-ish dialogs you can launch with PrintDlg[A], this one is called the "Print Setup" dialog according to Microsoft.

This dialog only asks for, by default, the page size/source and orientation. These seemed like the most harmless options and, at least for me, the page size option maps well to the one in the Epilog printer settings dialog. (The source only has the option of "laser bed".) If I recall correctly the Epilog "printer" disabled the "landscape" option. You can modify it by supplying template information to make it look how you like, but I didn't feel the need. (Hence my "two-ish" above.) I've also disabled the "Network button" (don't know if that hurts anyone).

PrintDlg's other dialog is just the default "Print" dialog which asks about page ranges (all, current, specific pages), collation, etc. None of which apply to a vector output device like a laser cutter. It also has a "Print to file" checkbox.

AMcBain (mcbain-asm) wrote :

To correct myself above, copies and collation don't apply. The page selection (all, selection, current, ranges) could apply if the bugs on multipage support ever landed.

As to the network button, it lets users select a printer from the local network that likely hasn't already been setup and recorded in the printers and devices control panel area previously. So there's probably not any harm in showing it.

AMcBain (mcbain-asm) wrote :

So it's been a while, but I haven't forgotten. I've been quite busy with work unfortunately. I have a few bug fixes I've added to my personal copy but none for the above issue that's currently blocking us.

I think I have an idea (if I didn't already mention it above) which is to try to allocate extra space for the buffer the struct I pass in to the Windows print dialog. The reason for this is the one I use has a pointer to printer data (unspecified, but printer specific) that is noted to start after the struct itself. So if we're getting access violations, it would seem that Windows is either trying to read or write data past the end of the struct where it expects this data to be.

I'll see if I can get something like that trialed soonish locally (to make sure it doesn't cause any issues here first, as I had none before). I'll post here when I have something to try.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers