I have no idea how well this will work as a thread but I thought we would give it a try.

Undoubtedly there are items that are not adressed in SP1 that have been distilled on these forums. When you folks get to the root cause of an issue that you would like to see changed I would ask that you reply to this thread with a quick synopsis of the issue and a link to the thread so we can follow the discussion.

This thread could go sideways but for eveyones benefit let's try and keep a clean thread.

Thanks folks!

T.

 

Link to discuss on Print Merge feature that has not been corrected in SP1

http://coreldraw.com/forums/p/7045/26273.aspx#26273

Hello,

Still having problems seeing thumbnails in Windows explorer for image file types associated with Photo-Paint X4 - CDR and CPT files display the corrent thumbnail image in Windows Explorer, but JPG, TIF, and PNG files that are also associated with PP, display only a high-res PP document icon.

This bug seems to affect all versions and editions of Windows Vista (x86 or x64)

Theres a thread about this on the Photo-Paint board at:

http://coreldraw.com/forums/t/4426.aspx

 

 Can the "Not for resale" be removed on the title bar. When minimized it looks like the "Not Responding" message. It gets really annoying.

Adrian,

Obviously the "Not for Resale" only shows up on copies that were supplied on
NFR versions. This would include people like beta testers, media, etc. I've
complained loudly to Corel about this as I have to do thousands of screen
shots and training classes and it looks awful. They've told me there are
other flavors that will get similarly dumb messages on the title bar.

I'm sure this was done as some small stab at preventing piracy and it sure
looks like a very bad decision to me.

What I'm told is that you'll have to get a new serial number from Corel,
completely uninstall and then reinstall with this new serial number. Ugh.

 Another issue.... whenever importing certain *.pdf files into Draw certain texts and images are "dropped out". I don't mind sharing that file to help it getting resolved.

 Regarding the dialogs for making custom icons in Customization options. I would like to see the Palette colors returned. As it is now we only have a gray palette. Even if we make our own in PP to import, we cannot import them with colors. I did find a workaround, but it would be better to have the palette colors back.

Patti

With SP1, I now really like X4, with one exception.

I still greatly dislike the much slower save (compared to X3 and before) when working on files that contain large raster images.

The problem is that X4 now zips the whole file up no matter if you choose "enable bitmap compression" or uncheck it, AND the zip process is horribly inefficient as it is not multithreaded and uses only one CPU core.

Thus on a current 3 Ghz quadcore xeon with a raid 10 array for storage, the X4 save file function is 4x slower than the X3 save file function. This is a real (unnecessarily) time waster for me with the new version.

I think the ideal thing would be for X4 to use a zip process that can multithread the opreation over multiple cpu cores. Multi-core CPUs are here to stay and we'll soon be seeing more than quadcores even. The single threaded save operation needs to be updated. Or just give us back something like the old way where we can disable the compression and put all the file assests in to a folder or an uncompressed tar file, etc. for speed.

I earlier reported that the Image Slice function produces garbage when viewed with a browser.   The problem seems to be related to larger images (I was working with one that is 8571 x 967 pixels).  

I used the slice function extensively a few releases back, but have not had a need for it until recently when I discovered it was not working.  I also found that it fails on the same image in X3, as well as now with X4 including X4 with the SP1 fixes installed. I don't have the earlier releases available any longer.

My error report on this problem was assigned Reference # 080415-000074 in a response dated 04/18/08.

drop shadow on artistic text + outline + behind fill

acts as if the text has no fill...meaning only the outline portion receives a drop shadow.

if i convert the text to curves first, then apply the outline, and select "behind fill"  the subsequently applied drop shadow behaves fine (or "normally" rather.)

 

bitmap pattern fill + magnify lens

try this combo with a few x magnification...the "bitmap pattern fill" looks okay without the mag, but a pixelated mess magnified.  it does this when you export & print as well, so it's not just a view mode thing. 

if you convert the "bitmap pattern fill" to a "bitmap", then overlay a magnify lens, the pattern looks fine.  that's not a solution to the problem tho, just a temporary workaround.

 artistist text + break apart = no size update in property bar

i think i've seen a similar lack of "object size" update while doing something similiar, but can only think of this one off the top of my head:

create artstic text in helvetica for example reading "XO."  now, when you break it apart (ctrl-k) stare at the object size box on the property bar.  it will not update the size of the individual letters.  to get it to update the size, you have to select each letter individually. 

is this really a voiceable problem? 

well, it shouldnt be.  if corel could size text based on x-height that would be lovely...but that's another thread.

Island:

I still greatly dislike the much slower save (compared to X3 and before) when working on files that contain large raster images.

 

 

We are told that one reason for this is to make the CDR and CPT file more accessable to other apps so they can peer in and make previews and such. For me that is an equitible trade.

We are told that one reason for this is to make the CDR and CPT file more accessable to other apps so they can peer in and make previews and such. For me that is an equitible trade.

I don't use any other applications except for coreldraw to work on my coreldraw files, but I can see the future potential I suppose if I needed to manage coreldraw files with some digital asset management program.

Still, I consider this an extremely poor implementation if this must be the way of the future.

Can't the files be (optinoally and easily) packaged in a way that doesn't force me to re-zip the whole contents hundreds of times in the corse of each job, for no purpose?

I can throw plenty of disk space at it and don't need the conservation -- I'd much prefer speed like I used to have to saving disk space which I have hundreds of gigabytes of free.

Can't the zip routine use more than one cpu core?

I don't mind throwing more money at the problem if this is the way of the future, but the fact that it's coded not to take advantage of current hardware (duo and quadcores) and without even an option to set the zip level to very low for faster speed is a very poor implementation that has be still using X3 for big jobs to save time.

You may not use other applications. The rest of us might.

Not everyone has disk space to throw around.

The Zip Routine uses 3 cores on my computer every time I do a save as. Core 3 seems to be the most used at 55%, Core 2 and 1 stay below 30%.

X4 is routinely using all 4 cores of  my Quad. I have a meter that gives me live Core Usage and it is not unusual to see four cores at 50% during a complex operation. It is also not unusual to see 1,2 or 3 cores working at a time during less processor-intensive operations.