Vector Graphics

[Programmer]

Pants, I spoke too soon about having received those decks. I got the email but now when I go to look at them I see there is nothing actually attached. Maybe the attachment was too big for my mail provider? Perhaps you could try sending them again in separate emails?

[Programmer]

Thanks for sending the cards. The the first thing I tried was what I was hoping for - I opened them in the original sample program that came with the SVG library and they looked just fine, whereas in the program they didn't look right at all (not exactly as you described but still not right - the circles were just black plain black blobs etc). It took me quite a while to work out why the same code was working in the sample program but not in the tarot program, but finally the obvious explanation occurred to me which was that somehow for the program I had got hold of an old copy of the DLL. With that corrected it looks much better. I can still see the anti-aliasing with the rings but apart from that they look fine, 上中 and 下 all showing up nicely. Take a look at the latest version 9.4.1.8 and I hope you will agree.

The bad news is that I have now run out of development time this for this summer. As of next Monday we are back to the normal timetable and since the start of this week the summer vacation truce where everyone holds off from starting new projects is clearly over and the work has been piling up on my desk. For the sake of my sanity I am going to be reserving my weekends for something other than programming (bug fixes being a different matter but as far as new development goes). That doesn't mean I will stop welcoming ideas for new features. Maybe we can get a new thread organised with the purpose of prioritizing these for the next phase of development.

PS, in this version I also fixed it so the space bar dealing works when the deck is parked.

[Greg the Yeti]

I've installed 9.4.1.8 and tried out the two SVG Decks I sent you.

The Ring version, which was a simple SVG export of the graphic works well apart from the "Anti-Aliasing" issue. It seems to be quite "snappy" too. The graphics are very small and are displayed very quickly. No delays on Shuffling and Dealing.

The Disks Version works, but not as anitcipated. Well I'm glad in a way, because I didn't want to go down that route anyway - it was the very old style way of constructing Vector Shapes!! Not very user friendly!

The "Anti-Aliasing" issue is the make or break issue now. Can it be switched off? either automatically when a Deck is using "Transparency" or permanently, since in the case of Orphalese the benefits of "Anti-Aliasing" are outweighed by the negatives!

For the time being I might experiment with a version with those same graphics on a BLACK background (should work). With Transparency on it should give an effect with a black edging to the graphics, which might be acceptable? Unlike the "white jaggy edging" which looks just naff!

It would still rather limit artistic freedoms in designing or converting Decks for use with Transparency, however with a Deck such as the Marseille which is "Woodblock with Colouring" efffect and DOESN'T need transparency, this might make it possible?....

When I have a little more time I will see about converting a card or two of the Marseille, to see if it would work as I anticipate it might. To keep files small and fast I would probably drop the modern adaptions of Marseille (with gradations of colour - "fountain fills") and go for a more original "Solid Blocks of Colour" look.

From the Awesome Tiger example, it seems as if SVG doesn't cope very elegantly with "Fountain Fills". Instead of the "Fountain-Fill" which one can apply in CorelDRAW or Illustrator, it requires a fan of overlapping shapes in a gradient of colour. It was these which slowed down the rendering of the Tiger so much...

Unfortunately a lot of my work in CoreDRAW is specifically designed to make use of transparency, so won't work well yet. Shame!

I just hope that (when you have time available) you are able to find the "Auntie-Alias" Switch!

Regards
Greg the Yeti

P.S. - I'm impressed with you finding the appropriate "Upper" "Middle" and "Lower" chinese symbols in a font.
P.P.S. - My comment about the DLL being an old version seems to have been spot on! Yo!

[Programmer]

I have checked the available methods and properties and I don't see anything to do with anti-aliasing. I am no expert at all when it comes to vector graphics but when I open one of those images in Paint Shop Pro I see something like this:

Close up of image opened in PSP

psp.jpg (17.86 KiB) Viewed 6677 times

This is just on opening the file, i.e. without doing any modifications of any kind. Clearly there are various shades of grey in the line of pixels all around the edge of the dark area. Unless Paint Shop Pro is applying anti-aliasing immediately on opening the file it seems to me that this is a feature of the image itself. As you are creating an image that should only consist of two colors, i.e. black and whatever your transparency color is, maybe you could prove (or disprove) that the effect is coming from the program by defining a color palette only consisting of those two colors?

[Programmer]

BTW, finding those characters was no problem at all because I have been struggling to learn some Chinese for the last few years now and so I have the Chinese IME already installed on my machine ;-)

[Greg the Yeti]

Hi,
Thanks for looking, but if you can't find any setting to do with "Anti-Aliasing" then that's bad news. Very clearly it IS being applied, but if it can't be switched off then this will effectively limit the use of Vector Graphics for Orphalese Decks. It won't be possible to use it for Decks intended to use the Transparent Feature.

If you are opening those SVG Deck images with Paint Shop Pro (a primarilly Pixel based program) then it WILL have added the "Anti-Aliasing" you are seeing.

You asked about proof of that:-
The only DIRECT proof of that would be for you to open the SVG images in a Vector Based Graphic Program...
However EVEN in that case there will still be a level of "Anti-Alising" applied - all computers use it to display anything on the Monitor or Screen. So any "Screen Capture" will still show "Anti-Aliasing"!!!
However by suitable sizing of the image it should be possible to see what is going on. As the image is made larger, the "Anti-Aliasing" pixels will not be magnified into larger "blocks", but will continue to be a single line of pixels on the edge. Applied dynamically by the program displaying the vectors on the screen.

A less direct proof would concern the GIF format Deck I also sent you. This was prepared directly from the CorelDRAW Vector File, without using "Anti-Aliasing" in the Export of the Cards. As you correctly surmised you will find that the GIF files are using a restricted Palette of only two colours - Black and White. The edges of the shapes in that GIF Format Deck are slightly ragged with steps along the curves, but you should see none of the intermediate tones of grey...
Since the export to GIF has converted the smooth "curves" to "Stepped Shapes" it consists of only straight lines, which will not have "Anti-Aliasing" added at the Screen Display stage. Straight Lines or "Stepped Shapes" do not require it.

Regards
Greg the Yeti

[Greg the Yeti]

Just been out walking with the Dogs and pondering the problem. A few ideas emerged...

1) Using my "Best Orphalese Thinking" I used a white background with those SVG files. Just as I had done with the GIF files.
A background of some kind seems to be required, since otherwise you get weird sizing problems (mentioned elsewhere). The background nicely defines the correct size of the card.
However with a vector file "Anti-Aliasing" could work three ways:
a) With a white background it will mix the shape with the white of the background producing the nasty "White Jaggies" around the edge. The effect I've tried hard to avoid!
b) With a transparent background "Anti-Aliasing" cannot work "per se", since you can't have intermediate shades between whatever colour the shape is and transparent!!! So perhaps this would be a way of switching "AA" off??
c) But what if, with a transparent background, it doesn't work that way, but instead "Anti-Aliases" correctly with whatever is being displayed as the background in Orphalese (ie NOT with the Card Back). Now that would be a very positive and desirable effect.

Posibility c) is worth investigating and so I will do a test "Post Hast" - as soon as I can...

If this doesn't work, there would still possibly be another solution:-

2) (This would require working on the Graphic System within Orphalese and how it dsiplays those Transparent Decks.) What if Orphalese treated Cards with a transparent background differently? What if instead of the current method of "Making the colour in the Top Left Pixel transparent" (for transparent Backgrounds only?) it correctly used the Background being Displayed by Orphalese for the Deck. I.E. if the dll is being fed the Deck's Background (or the Program default if none is chosen) as the background with which to "Anti-Alias".
This might happen automatically but possibly only if the card has no background of it's own?
This would leave two possiblities:
a) To fool the dll into thinking that the Deck Background was it and to ignore the Card Background. I don't know if that's even possible?...
b) To somehow remove the requirement of a background for the correct sizing of cards.
Perhaps an optional setting to manually define the "pixel/mm size" of the cards?
All that hard work with no guarantee that it will even work.......

I'll get the test I mentioned, in 1) above, done as soon as possible and post the results here.

Regards
Greg the Yeti

[Greg the Yeti]

Hi, just got back from Shopping and have rushed to do those tests I promised.
I've already sent the resultant Decks to you Richard.

1) Using a Transparent Background
Still has white "Anti-Aliasing" Edge - Damn!
I think this may be because the SVG format "assumes" the white background of the "Page".
I found in one of those earlier experiments that SVG exports the page, which determines the size of the resultant graphic. Even though that "Page" is not listed as an "object" in the SVG file (I checked) it's still there - assumed and used by the dll as the "Background" with which to dance the "Auntie-Alias".
In this Deck the "Page" and the Transparent Background are both of identical size. Effectively the Transparent Background which I added here is just being ignored! - Damn!

2) Using a Black Background (as I suggested in an earlier post)
Has a Black Edge, which could be made as wide as I wish by editing in CorelDRAW. It does look better than the "White Jaggies", but I still think it looks like it's been produced by a rank amateur (who doesn't know how to remove the edges to his shapes).

Experiment No 2 is probably the only available option for transparent Decks unless you can work on how Orphalese works with that dll.... It's a bit reminiscent of older Block Printed Decks such as the Marseille? It looks like "Block Printing Style" is the best we can do for the moment - unless you can come up with a miracle!

Regards
Greg the Yeti

[Greg the Yeti]

Thinking about that second test above:- What if I use a "Background" and "Edge" which are sufficiently close to the colour of the Main Shape to be indistinguishable to the eye. Orphalese's Transparent Function should still do the business but the "Aunti-Alias" will have very few colour tones with which to goof up with. The result might look acceptable??

The only drawback to this "solution" is that it would limit me to a single colour. (Come back Model T Ford - all is forgiven!)

I'll do the experiment and forward the results...

Regards
Greg the Yeti

[Greg the Yeti]

Just done that test - and with a usable result!

It's a little limiting in colour choices, but the result is a Deck that works!

With a little more time I'm sure I can get the colour match of Shape with Edge and Background a little closer (within the necessary RGB Palette).

I will rush the Deck to your inbox, so you can see it!

Regards
Greg the Yeti