-
Evening all,
Forgive me if these are FAQs - I may have missed
them in reading the documentation, and I'm new
to the forum.
I've been giving some feedback/suggestions to
the people at Xara for Xara X, having used
CorelXARA 2 intermittently for a couple of years.
Obviously they're quite busy, so I wanted to
check here to see whether you could help out.
Firstly, I had a problem printing to PostScript
(going to a printing bureau) where colours
matching on screen didn't match when printed
(specifically an ellipse used to cover a bitmap
blemish). AFAICR the ellipse colour was specified
in HSV; the image was an RGB TIFF. I can believe
the suggestion that the difference is only there
in CMYK, but I'm not sure how to tell. ArtWorks
has a "view separations" options, but am I right
in saying there's no way to preview this (other
than, possibly, printing the separations and
viewing them separately) in Xara?
Secondly, from problems with the same file, has
anyone had trouble with Xara reading large (e.g.
20MB) TIFF files under Windows95? It's quite
possible that my problems are with the machine,
since it seems to be unstable anyway, but the
file seems to be getting corrupted when it's
written.
Speaking of printing, my third question. Having
found out the hard way about manually setting the
transparency resolution - 200dpi blocks are very
visible on a 2400dpi postscript image - I
recognized the problem when I was trying to print
some bitmaps (well, pattern filled rectangles -
is there a difference?) This time I was trying to
print some high resolution images on a 1440dpi
Epson photo printer. I could increase the image
resolution by changing the "transparency
resolution" to 360dpi, but was a bit surprised
that it doesn't seem possible to set the value
above 600dpi, and that it seemed to use more
memory that I was expecting. Is this really the
control I should be using? 360dpi seems to be
enough in this case, but the quality is lower
than I would have liked given the capabilities
of the printer. Changing the resolution also
seems to provoke crashes under Windows 95 (though
not under Win98), but I could believe my machine
(or the printer driver) is just broken.
Thanks in advance for any help you can give,
Fingers crossed for grouped transparency making
it back in a future version of X...
Andrew Garrard
(Upgrading to Xara X next month)
-
Evening all,
Forgive me if these are FAQs - I may have missed
them in reading the documentation, and I'm new
to the forum.
I've been giving some feedback/suggestions to
the people at Xara for Xara X, having used
CorelXARA 2 intermittently for a couple of years.
Obviously they're quite busy, so I wanted to
check here to see whether you could help out.
Firstly, I had a problem printing to PostScript
(going to a printing bureau) where colours
matching on screen didn't match when printed
(specifically an ellipse used to cover a bitmap
blemish). AFAICR the ellipse colour was specified
in HSV; the image was an RGB TIFF. I can believe
the suggestion that the difference is only there
in CMYK, but I'm not sure how to tell. ArtWorks
has a "view separations" options, but am I right
in saying there's no way to preview this (other
than, possibly, printing the separations and
viewing them separately) in Xara?
Secondly, from problems with the same file, has
anyone had trouble with Xara reading large (e.g.
20MB) TIFF files under Windows95? It's quite
possible that my problems are with the machine,
since it seems to be unstable anyway, but the
file seems to be getting corrupted when it's
written.
Speaking of printing, my third question. Having
found out the hard way about manually setting the
transparency resolution - 200dpi blocks are very
visible on a 2400dpi postscript image - I
recognized the problem when I was trying to print
some bitmaps (well, pattern filled rectangles -
is there a difference?) This time I was trying to
print some high resolution images on a 1440dpi
Epson photo printer. I could increase the image
resolution by changing the "transparency
resolution" to 360dpi, but was a bit surprised
that it doesn't seem possible to set the value
above 600dpi, and that it seemed to use more
memory that I was expecting. Is this really the
control I should be using? 360dpi seems to be
enough in this case, but the quality is lower
than I would have liked given the capabilities
of the printer. Changing the resolution also
seems to provoke crashes under Windows 95 (though
not under Win98), but I could believe my machine
(or the printer driver) is just broken.
Thanks in advance for any help you can give,
Fingers crossed for grouped transparency making
it back in a future version of X...
Andrew Garrard
(Upgrading to Xara X next month)
-
let me comment on the issues I'm most familiar with:
1. Covering a bitmap with a vector object isn't the best way to cover blemishes. The 'right' thing to do is fix bitmaps in dedicated bitmap editors like Photoshop. That way to can be sure that any changes will match their surroundings
2. I've imported VERY large bitmaps into Xara, and it is incredibly fast.
3. You don't want transparencies to be that high resolution. You don't need them to match printer resolution... line screen is what matters and at best you only need to double that.
4. Make sure show printer colors is turned on!
Well, hope these help.
Nathan Heagy
<HR>
Blow Your Beef Away
Cow Comics!
-
Hi Nathan, thanks for replying.
1. Fixing the bitmap in Xara rather than in a bitmap editor. Yes, I know; unfortunately the only decent bitmap editor I have access to is on a low memory Mac, which struggled with the image in question. I'd already done most of the layout (including some Photoshop filters applied in Xara) when I noticed the blemish, so I was hoping the quick fix would work to save me shifting stuff between machines and reapplying my filters.
2. Glad Xara has been seen with large images; that probably just means my machine's unstable, so I'll upgrade my main box to Win98 and hope it fixes everything.
3. Transparencies only needing to be line screen resolution. Twaddle (no offence). Xara converts all transparent objects to bitmaps for printing; my original case with transparency was a bit of largely monochrome line art that contained small transparent sections. It happened to be a small and detailed logo on a leaflet. 200dpi mangled it horribly, at 2400dpi the line art is smooth and all details are visible. In the end, in this case, I turned off transparency because the resolution was more important - the transparent sections were only visible when the logo was printed larger. That was a feature of that particular design, though - had I used a drop shadow, or some other large feature, I wouldn't have had this option. If the transparency resolution rectangles were used as a mask and the vectors drawn for each transparency step, this wouldn't matter (although the resulting PostScript would be huge).
In the case of my bitmap printing, there are sharp edges in the photographs that are being aliased when the transparency resolution is set to a low value. These are highly visible at 200dpi, less so at 360dpi (which is what I settled on). Since in this case I was using an inkjet printer with a 1440x720dpi error diffusion quantization I would expect it to make a reasonable effort at higher frequency image information than the 360dpi I used. I'm not familiar with the Windows printer driver mechanism, though (other than noticing how often the Epson drivers seem to crash), so my objections may be unreasonable.
4. Show printer colours was turned on. However, my printing problem was with a page that was exported (using the printer driver provided by the printing bureau) as colour PostScript, and the result was then rendered on a monochrome process. I can only assume the monochrome rendering is giving a different bias to the different virtual CMYK plates from that which Xara (or the printer drivers) are assuming. Without actually being able to check for a match in the plates - of which I assume Xara has control, since it has typesetting options for individual plate export - I couldn't check whether the match would work. Obviously it's a lot of work to build in to a new release, I just wondered whether it was there already and I'd missed it (since ArtWorks had it).
I should say I wouldn't trust CorelDRAW as far as I could throw it for doing this work; Xara has been extremely useful to me so far, I'm just struggling slightly with these few features.
Thanks again for your feedback,
Andrew Garrard
-
Andrew
If you don't want to shell out for the latest version of PhotoShop, look for free versions of bitmap editors on the front covers of computer magazines. Even early versions have adequate tools for touching-up bitmaps and some are very sophisticated. Having said that, you can get round not having a bitmap editor by creating a same-size bitmap copy of the original with its vector patch.
If your patch was a simple non-transparent vector shape, its colour model would have been retained in the EPS file and possibly rendered differently to how it appeared on screen. If you think that was the problem, just change the colour to an equivalent that uses an RGB model. Alternatively, the patch colour may seem better on screen than it is with real printing ink. Use a colour picker (available in the shareware Xone if you haven't got one) to select a suitable colour from the original bitmap. Also, converting to greyscale assigns different weights to the RGB colour components and two apparently similar colours may render as different levels of grey. If your intended output is greyscale (or monochrome from greyscale), try converting the bitmaps yourself to see how they'll look.
AFAIK, Win 95 doesn't limit the maximum size of bitmaps Xara can handle, which is about 48Mb using the default version of Xaradraw.DLL. A lack of real or virtual memory (temporary disk space) will reduce the maximum and may make Win / Xara unstable. To manipulate and make copies of 20Mb bitmaps you'll need at least 48Mb of RAM with an equal amount of virtual memory for minimum comfort. From my recollection of a previous experiment, I think that 19Mb is about the largest bitmap that a 32Mb Win 95 / Xara 2 system can handle.
Xara resamples embedded bitmaps using a relatively crude nearest pixel algorithm (soon to be improved, I believe) which can create some ugly effects when the dpi of the printer and bitmap aren't related by a whole number (by contrast, EPS bitmaps created from transparent vector objects, say, are anti-aliased, giving all the resolution enhancing effects that we see on screen). You can overcome the problem by using ever higher export dpi, but this is a sledgehammer to crack a nut. A more efficient solution is to resample the bitmaps on the page to a whole fraction (half, third, quarter etc.) of the printer's maximum dpi using some form of interpolation. (Bi)linear is best for enlargement and bicubic is ideal for reduction, although (bi)linear followed by an unsharp mask may also be effective.
Regards - Sean
-
Sean,
Re. bitmap editing, you're right - I should have done it a different way, and I will in future. Using Xara to do a make bitmap copy is a good workaround, thankyou. I'm still a little confused as to why the colours were different, since as far as I could tell both image and patch were defined in RGB and I thought I'd matched the components, but it's possible I was just being incompetent. I still think it would be nice to have ArtWorks's ability to edit with selective plates shown (Xara XI, perhaps).
The memory may have become limited on my machine - especially on disk, while I wasn't looking. I was certainly using the default Xaradraw.DLL, so I'll put the large memory variant in place and see whether it helps. And clear out my hard disk a bit. :-) The bitmap was originally edited in a machine with only 24MB of RAM (although my current box is 96MB), so it may have been mangled at an early stage. I'll try extracting the image and checking it in another application, then restore the file to Xara. Could be a legacy problem.
I spotted the nearest pixel on bitmaps while printing - glad to hear that may be improved. My particular case was genuinely a lack of resolution, rather than aliasing, but I agree this can be a problem. On those grounds it's a pity that Xara 2 seems to top out at 600dpi - hence my choice of 360dpi when targetting a 1440x720dpi printer. The slight increase to 720 dpi would have been welcome, but - as you suggest - I felt a multiple of the printer resolution was the safest bet.
Regarding your interpolation suggestions, you have me intrigued. I know a little about sampling (I work for a 3D graphics company), but not in the real-time sense - i.e. I know about accumulating samples for given filter kernels, but not much about resampling existing images. Would you mind giving some background on the bilinear/bicubic sampling selection?
Which reminds me of another thread I meant to start...
Thanks again for your help,
Andrew
-
Andrew
Further to my earlier reply, I find that bitmap resolution on the page should equal or be an integer division of the Print Options > Output > Transparency resolution > Pixels per inch value to avoid low quality resampling. The Transparency resolution should be set to an integer division of the printer's maximum dpi, as stated before, although this may be less important due to the blurring caused by the printer's dithering pattern. In fact, on a 600dpi HP printer, I found that a Transparency resolution of 300dpi gave the best results for both 300 and 600 dpi bitmaps. This is probably highly model dependent and some experimentation will be necessary.
Anybody who's eyes glazed over before they finished the first paragraph should at least note the following: Xara's Print Options > Output > Automatic setting appears to be anything but automatic, remaining at 150dpi regardless of the printer selected. As a first approximation, click Manual and enter a value of half your printer's maximum dpi. I assumed that Xara interrogated the printer driver and made an intelligent choice of value ... silly me ;-) Also note that this setting is local to the drawing, so it has to be saved with the default template to become the default.
My attached diagram shows how five pixel values (red dots) might be used by linear (blue lines) and cubic (grey line) interpolation to produce new pixels at points indicated by vertical dashed red lines.
Linear interpolation works by taking the two pixels either side of where the new, interpolated pixel is going to be and draws a straight line between them. The value of the new pixel lies somewhere along that line and is a weighted average of the original two pixels. Averaging is synonymous with blurring and this technique tends to blur the edges of images.
Cubic interpolation uses four adjacent pixels to construct a cubic curve passing through all of them. It therefore takes account of how the pixels are changing beyond the immediate vicinity, rather like the behaviour of Bezier lines which also use cubic interpolation. This allows the new pixel to lie outside the range defined by the original pixels or to be disproportionately close to one or other of its neighbours, as shown in the diagram. The end result is that reduced bitmaps are less blurred and better retain their edge definition.
When enlarging bitmaps, however, it's usually not desirable to emphasise pixel boundaries, so the smoothing effect of linear interpolation is preferable. This is particularly important when enlarging JPEGs because their compression uses a sort of dithering that introduces shadows along edges which would be magnified by cubic interpolation. The Bi of Bicubic and Bilinear refers to the fact that the pixels are interpolated in both horizontal and vertical directions. I think that Xara uses Bilinear but just calls it Linear.
Regards - Sean
