I understand SVG would be attractive to Xojo because of the Web edition, so it will probably happen… But on the desktop despite the complexity, from our perspective, outside of those working with high end graphics software , PDF would likely be the better choice…
Because OS X has some built in PDF support, I would guess that if a Mac vector format emerges it would me from that direction… and it is current the one most supported, even if not ubiquitous.
PDF was designed to be an output graphics data only and not to be an exchange format to be reloaded and recovered.
Outputting PDF is also a known request. <https://xojo.com/issue/10701> Top 5 now.
This is exactly why Object2D on the Mac hasn’t switched to PDF. It’s no problem to create it using Mac-specific APIs, but it would be miserable to take a PDF and ‘recover’ an Object2D.
My PDF Class (which is still awaiting a fix to image commands 
) works perfectly in translating O2D objects into PDF based code… So it can be done… .The translation is not simple, and requires a more than rudimentry understanding of the internal PDF format, but it can and has been done
Going from O2D TO PDF is not the hard part
Going from PDF to O2D is
[quote=110884:@Norman Palardy]Making Carbon support the new framework IS what motivated this decision since it’s a such big job.
It’s basically a whole new framework for Carbon.
And we already know its a dead, won’t support new technologies won’t be 64 bit and a host of other things.
This is unfortunate as Carbon is a really nice API for what we do.
Its just not what Apple is pursuing / promoting.
Theres no really widespread options
PICT’s death left Apple in a weird state where there’s no widespread vector graphics format that you have readers & writers for.
PDF works for some things but not in all apps.
Some can read some can write some can do both.
SVG is not widely supported.
And … then
there’s not much else[/quote]
Yeh, Carbon is dead but is still supported by Apple and is the only solution as far as Xojo is concerned if you need to support operating systems < Mac OS X 10.7
It is not as if the current Xojo version did not support Carbon. And 2013 3.3 supports systems prior to 10.7. At one point, PPC was dropped too in its time.
@Kevin: nobody forces you to upgrade to 2014r3. As long as you need Carbon support you can still use 2014r2. But you really, really need to go for Cocoa. It’s like a visit to the dentist or the tax guy. 
Vector Graphics (VG):
2; Do we need a standard to follow ?
I think we need a format that allows us to read vector graphics files regardless of the OS and be able to Import / Export through all running applications that are Graphics savy.
We need to be able to write VG to disk, sent them via internet and read them OSless (on all suported platforms) AND read them NATIVELY on all platforms.
On the case of Import / Export in graphics supported applications (say word processors, dtp, etc.), a rendering option can be done for that purpose.
Clipboard:
On OS X (and I assume that it is the same on the two other platforms), when you copy an image on the clipboard, you get many images of different types. A screen shot (on OS X) store in the Clipboard images for these types:
{{«class PNGf», 109970}, {«class 8BPS», 255996}, {«class BMP », 833634}, {«class TPIC», 221217}, {TIFF picture, 840290}, {«class jp2 », 62647}, {GIF picture, 50793}, {JPEG picture, 92868}}«class PNGf», 109970 this is the native format (and image size in bytes).
8BPS is PhotoShop format, etc.
So, a VG format have to works like the above shows: have its own format in the clipboard and some renderings to be able to be put in Graphics compliant applications.
Am I right on what we need ?
Now for the standard to use: do we need to give the feature set or can we let Xojo decide what the minimum set of feature have to be supported ?
For me, the file format is not the important part, the important part is its wide usability in all platforms we can build applications for. If SVG can do the job: OK for me. Else, another format can be used.
At last: if we can give our opinion, isn’t it better to create a conversation to talk about Vector Graphics (only) ?
Non of that was ever being disputed. Our Cocoa transition is being influenced by business decisions within the company and not (for now) technical reasons.
For the time being, we need to fully support 10.4+ which is one reason why we have not finished our transition to Cocoa (we are making internal changes behind the scenes to simplify the transition). This is from paying customers so we have to base our OS support on paid usage figures.
We also have to maintain compatibility with the documents our apps create for a certain length of time. At some point during RB2008, the way font names were generated under OS X changed which broke our documents. This has meant we have had to stay on RB2007 / RB2008r1 for one of our apps much longer than we would have liked. All attempts to map the font names from old to new did not work 100% so we have had to wait until we replaced all text editing with a solution that is not affected by operating system changes or RB changes.
Anyway, my original point regarding Carbon being dropped is irrelevant as Norman has confirmed that Carbon was never going to get the new framework so our original plan would not have worked.
Really? I know some still using 10.6.x but lower?
Yes, we can get day by day stats on what operating systems people are running our software on and where our revenue is coming from. We only dropped PPC support last year due to stability issues when using CURLSMBS and SSL. The good news is that the numbers for older operating systems are dropping but they are still significant. We are hoping that over the next 12 months we can abandon these operating systems without upsetting too many people.
Carbon as a UI toolkit is pretty much 100% deprecated by Apple.
If you need to support OS X < 10.7 you can’t use the latest version of Xojo anyway.
[quote=110935:@Emile Schwarz]Vector Graphics (VG):
I think we need a format that allows us to read vector graphics files regardless of the OS and be able to Import / Export through all running applications that are Graphics savy.
We need to be able to write VG to disk, sent them via internet and read them OSless (on all suported platforms) AND read them NATIVELY on all platforms.
On the case of Import / Export in graphics supported applications (say word processors, dtp, etc.), a rendering option can be done for that purpose.
Clipboard:
On OS X (and I assume that it is the same on the two other platforms), when you copy an image on the clipboard, you get many images of different types. A screen shot (on OS X) store in the Clipboard images for these types:
{{«class PNGf», 109970}, {«class 8BPS», 255996}, {«class BMP », 833634}, {«class TPIC», 221217}, {TIFF picture, 840290}, {«class jp2 », 62647}, {GIF picture, 50793}, {JPEG picture, 92868}}«class PNGf», 109970 this is the native format (and image size in bytes).
8BPS is PhotoShop format, etc.
So, a VG format have to works like the above shows: have its own format in the clipboard and some renderings to be able to be put in Graphics compliant applications.
Am I right on what we need ?
[/quote]
We need one that is readable & writeable in your software.
Having OS level support is nice because the likelihood that other programs can also use the output from your applications increases. And with OS support the likelihood you can use another tool then read those into your program increases.
And if its cross platform then what ever you write can read its own output on other platforms.
It would be better than using some invented format.
So it certainly would be desirable.
BTW output only PDF is very important to many even if we can’t import it back in. Please don’t lose sight of that.
SVG may produce pictures… but even it was pasteable into into Word , that does not help us when we need to generate standalone PDF documents for distribution via Email or downloading. Those are 2 very different needs.
Please don’t let the inability to read PDF’s back ins stop you form introducing X-platform PDF production support… You can’t kill 2 birds with one stone in this case with SVG. That feature request has been scheduled for a long time now…
No one from Xojo has suggested that SVG would be instead of PDF production
SVG would be used for
http://documentation.xojo.com/index.php/Picture.Save
Picture.SaveAsDefaultVector
And vector is the future for DPI independent works. One icon fits for all for example.
[quote=111000:@Karen Atkocius]BTW output only PDF is very important to many even if we can’t import it back in. Please don’t lose sight of that.
SVG may produce pictures… but even it was pasteable into into Word , that does not help us when we need to generate standalone PDF documents for distribution via Email or downloading. Those are 2 very different needs.
Please don’t let the inability to read PDF’s back ins stop you form introducing X-platform PDF production support… You can’t kill 2 birds with one stone in this case with SVG. That feature request has been scheduled for a long time now…[/quote]
in all my applications, i do not do printing to the printer directly since each user might have different printer and there ares difference ebetwwn inkjet and laser printer, difference between window and mac machine… the list is endless. So to me , ability to create pdf is very important.
[quote=111004:@Norman Palardy]SVG would be used for
http://documentation.xojo.com/index.php/Picture.Save
Picture.SaveAsDefaultVector
[/quote]
If it happens, I assume SVG would be valid for console applications as well in addition to JPEG and PNG.