On 2015-07-03 21:08 (+0200), Terry wrote:
> I've tried converting the stroke to a path, but then the fill > disappears.
Duplicate the path first - remove the stroke from the original, convert the stroke of the duplicate to path: thus you will have the original filled area, and on top of that the outlined stroke. You could also test other variations:
- Convert stroke to path, break apart, assign stroke color to the bottom path, fill color to the inner path stacked on top.
- Convert stroke to path, break apart, duplicate inner path, select just duplicated path and the outer outline, apply 'Path > Difference'. Fill the outer path with former stroke color, the inner one with the original fill color.
Such details about usage though are beyond the scope of the bug tracker. The reported issue is known - an upstream bug in the cairo graphics library, reported for Inkscape as well as in cairo's own bug tracker.
> Part of the issue is the drawing starts out much larger and then is
> shrunk to fit in the space allowed. This, of course, reduces the stroke
> size as well. The drawings are printed at 2400 dpi on glossy paper to
> give a very crisp image and much of the detail is visible.
I do wonder though why - if the output is intended for a much higher resolution - why the vector drawing is first scaled down from a huge size (roughly 550 x 650 inches!) to a miniscule size (0.5x0.5 inches aka 45x45 px (SVG user units)) and exported to PDF at this size … AFAIU there would be no issue with too small stroke widths in Inkscape's cairo-based PDF and PostScript exports if the original drawing had not been downscaled to and exported at such a tiny size.
> Any information on when the bug will be fixed. It seems its been around
> a long, long time.
When and how this will be addressed in a future cairo release is outside of Inkscape's own sources, and not something to be determined by the Inkscape project itself. Cairo is an independent software project, and Inkscape is merely a client of cairo (for rendering on-canvas and e.g. for export formats like PDF and PostScript).
On 2015-07-03 21:08 (+0200), Terry wrote:
> I've tried converting the stroke to a path, but then the fill > disappears.
Duplicate the path first - remove the stroke from the original, convert the stroke of the duplicate to path: thus you will have the original filled area, and on top of that the outlined stroke. You could also test other variations:
- Convert stroke to path, break apart, assign stroke color to the bottom path, fill color to the inner path stacked on top.
- Convert stroke to path, break apart, duplicate inner path, select just duplicated path and the outer outline, apply 'Path > Difference'. Fill the outer path with former stroke color, the inner one with the original fill color.
Such details about usage though are beyond the scope of the bug tracker. The reported issue is known - an upstream bug in the cairo graphics library, reported for Inkscape as well as in cairo's own bug tracker.
> Part of the issue is the drawing starts out much larger and then is
> shrunk to fit in the space allowed. This, of course, reduces the stroke
> size as well. The drawings are printed at 2400 dpi on glossy paper to
> give a very crisp image and much of the detail is visible.
I do wonder though why - if the output is intended for a much higher resolution - why the vector drawing is first scaled down from a huge size (roughly 550 x 650 inches!) to a miniscule size (0.5x0.5 inches aka 45x45 px (SVG user units)) and exported to PDF at this size … AFAIU there would be no issue with too small stroke widths in Inkscape's cairo-based PDF and PostScript exports if the original drawing had not been downscaled to and exported at such a tiny size.
> Any information on when the bug will be fixed. It seems its been around
> a long, long time.
When and how this will be addressed in a future cairo release is outside of Inkscape's own sources, and not something to be determined by the Inkscape project itself. Cairo is an independent software project, and Inkscape is merely a client of cairo (for rendering on-canvas and e.g. for export formats like PDF and PostScript).