[Nonsuch]

eWeek just posted an interesting article on the upcoming sea change in the DTP industry, with Apple's next generation of hardware being incapable of booting OS 9. That much we knew. However, there were two other revelations that were new to me:

While Apple's September announcement that as of January, new Macs will only boot into Mac OS X garnered much attention from the Mac community, Quark's simultaneous bombshell went almost unnoticed: During a session at Seybold Seminars in San Francisco, James Therrien, manager of professional services at Quark, acknowledged that the next major version of QuarkXPress will run only on Mac OS X and Windows�not Mac OS 9.

This was news. And it seems there's a very good reason:

Now Quark has announced the end of the line for XPress on Mac OS 9; not only will the new version run on Mac OS X only, Quark's Therrien said, it will comprise a different code base from XPress 5.0�not simply an upgrade optimized for Apple's Carbon APIs. (Adobe InDesign 2.0, which was released in early 2002, runs in both MacOS 9 and X.)

Now it doesn't specifically say Quark 6 won't be Carbon -- you can have a Carbon app that won't run in 9 -- but "a different codebase" does strongly suggest that it might be Cocoa. Except that would've taken so much freakin' work it boggles my mind. And yet, I imagine Quark engineers would relish the chance to scrap the XPress spaghetti code and start fresh, particularly if they're counting on remaining a strong presence on the Mac platform; you can only continue to build on a rotten foundation for so long. The article ended with this:

XPress 5 sales have fallen far short of Quark's expectations, as most professional publishers opt to stick with the five-year-old Version 4�or jump the gun and move up to Adobe InDesign, which with Version 2.0 has edged ahead of Quark in terms of functionality. And this is beginning to translate into market share, as an increasing amount of design studios, advertising agencies or magazine publishers are embracing Adobe's offering.

No statistics -- no one seems quite able to say how many Quark customers Adobe has already poached. But announcing a Cocoa version of Quark would be a hell of a way to win back Mac loyalists, no?

[Zimphire]

Depends, Quark;s snobby attitude towards everything including tech support has lost allot of customers. If they can pull off a great Quark for OS X I would be happier than a kitten in front of 10 nipples. Now just get their support staff back down to earth. I have to use Quark daily to design and paginate, the frustrations I have with it, and it's crashing can't even be described into words. Some of it IS OS9s fault, but sometimes even when you SAVE your work all the time, Quark will still corrupt your file.

I hope they fix this in the next version. It sucks to push and pull classifieds all night only to have to REDO them because Quark dumps on you.

[moki]

I highly, highly doubt it will be rewritten in Cocoa.

[Nonsuch]

Originally posted by moki:
I highly, highly doubt it will be rewritten in Cocoa.

How do you interpret the article, assuming it's accurate? Junk a lot of the old code and rebuild it as a relatively legacy-free Carbon app? (I guess that would be the only other option, eh?)

[unfaded]

Originally posted by Nonsuch:


How do you interpret the article, assuming it's accurate? Junk a lot of the old code and rebuild it as a relatively legacy-free Carbon app? (I guess that would be the only other option, eh?)

Probably. Just like Office X.

[sadie]

I would be very surprised if Quark, Adobe or anybody like that released a major app in Cocoa. Why? Because using Objective-C rather than C++ woul make it distinctly harder to reuse code in the Windows version (without an internal bridge between the languages).

Carbon is relatively similar to the Windows APIs. Cocoa is quite different. Therefore big cross platform application = Carbon.

There's nothing wrong with that, though - a fresh Carbon app is still a much better thing than an OS 9 port.

[Gul Banana]

Originally posted by unfaded:


Probably. Just like Office X.

Heh, except that Office v.X isn't! Most of it is just Office 2001 with a nice Aqua GUI stuck on.. it isn't even compiled as a Mach-O binary, which is utterly bizarre given that it runs only in OS X. The speed they could gain just with a recompile...

Then again, perhaps they don't want people using nm and hax0ring their program. Or something.

[Developer]

Originally posted by Gul Banana:
it isn't even compiled as a Mach-O binary, which is utterly bizarre given that it runs only in OS X. The speed they could gain just with a recompile...

CFM is faster than Mach-O.

[Guy Incognito]

Originally posted by Developer:
CFM is faster than Mach-O.

No!

[Guy Incognito]

Originally posted by moki:
I highly, highly doubt it will be rewritten in Cocoa.

I doubt it too but for their sake, I'd rewrite in cocoa in case Apple has to make an unfortunate switch to the x86 platform sometime down the road.

Imagine rewriting the whole thing and then realizing that Apple has switched to the x86 architecture. Quark will definitely not re-rewrite their program. At least not for another 20 years.

[Millennium]

It's possible. It would explain all the delays.

However, I doubt it's the case. Although Cocoa's portability issues are not nearly as bad as many Cocoa-detractors make them out to be (for example, the Cocoa port of Quake III uses only about 800 lines of platform-specific code), they do exist.

But the big thing is that developers have to learn a new API (namely, AppKit) when programming a Cocoa app. That's the main issue for most developers. Obj-C is absurdly easy to pick up if you already know C or C++, but the API is actually quite difficult to learn.

[TheTraveller]

Yeah, no way it's going to be a Cocoa app. I'm no Cocoa detractor, but there's no (practical) way the next Quark is going to work on both MacOS and Windows if it's written in Cocoa. Unless Apple makes an updated Yellowbox available for Windows. :-)

[MacGorilla]

For the time Quark is taking, you'd think that they are carving the source code into stone tablets!

[Adam Betts]

Originally posted by TheTraveller:
Yeah, no way it's going to be a Cocoa app. I'm no Cocoa detractor, but there's no (practical) way the next Quark is going to work on both MacOS and Windows if it's written in Cocoa. Unless Apple makes an updated Yellowbox available for Windows. :-)

Windows version of Quark is far better than OS 9. Less buggy, nicer interface (none of those "I'm made for OS 9 but I still use GUI from OS 6" crap)

It would make sense if they leave Windows version alone and rewrite Quark in cocoa for MacOS X. They have two completely different programming team for both OS. I'm sure there is some ways they can share codes that doesn't depend on programming language.

[CheesePuff]

Originally posted by Guy Incognito:


No!

I know you're probably just joking around, but it is, by about 200% in some cases, such as calling a function.

[Guy Incognito]

Originally posted by CheesePuff:


I know you're probably just joking around, but it is, by about 200% in some cases, such as calling a function.

In what cases? Can you provide me a link that explains why CFM is faster?

A quick google search seems to indicate that people perceive mach-O as being faster than CFM. But I'd enjoy getting hard data that confirms that CFM is faster in function-calling.

[voodoo]

Quark has taken an unusually long time to carbonise XPress, granted. This is Quark we are dealing with, they are not exactly the speediest programming company. How long was Quark in version 3? And version 4?

I dunno. It would be out of character for Quark to make XPress Cocoa, but here's to hoping!

[godzookie2k]

quark kicked ass (variable term) in version 3 and 4...most designers I know (99% maybe?) are running 3.x or 4.x.

[moki]

Originally posted by Millennium:
It's possible. It would explain all the delays.

However, I doubt it's the case. Although Cocoa's portability issues are not nearly as bad as many Cocoa-detractors make them out to be (for example, the Cocoa port of Quake III uses only about 800 lines of platform-specific code), they do exist.

No, it really isn't likely at all.

Quake is a poor example -- there was really not much reason to write it in Cocoa to begin with, other than Omni being familiar with Cocoa and not carbon.

Consider: the advantage of using an app framework is that it takes care of a lot of the GUI and other such functions for you. This is great, because someone else wrote a lot of the code you need to use for you already, with inherently proper behavior.

However, Quark can't take advantage of said frameworks if they still expect a good portion of their code to be xplat -- so there is really zero point in using Cocoa at all. The GUI handling code of an app like Quark XPress is a huge part of the application -- maintaining one codebase for Windows and another for the Mac would be an extremely poor decision on a number of fronts.

[moki]

Originally posted by Guy Incognito:


I doubt it too but for their sake, I'd rewrite in cocoa in case Apple has to make an unfortunate switch to the x86 platform sometime down the road.

Imagine rewriting the whole thing and then realizing that Apple has switched to the x86 architecture. Quark will definitely not re-rewrite their program. At least not for another 20 years.

What, pray tell, makes you think Carbon would be any worse off running on x86 than Cocoa would be? With the Carbon APIs, Apple has taken out hardware-level dependencies entirely.

Both Carbon and Cocoa apps that make poor endian decisions would need to be tweaked to run on a new processor architecture. Cocoa would certainly hide some of the issues for you if you used it properly, but it wouldn't be terribly different than compared to Carbon.

[kennethmac2000]

Originally posted by unfaded:


Probably. Just like Office X.

Except that Office X still contains a horrific amount of legacy code. When on earth are we getting long filename support (one of the biggest barriers to sharing files with Windows users in my environment)?

And it doesn't even have a completely Aqua GUI! Have you seen the drop-down menus in Excel workbooks?

[Millennium]

Originally posted by moki:
However, Quark can't take advantage of said frameworks if they still expect a good portion of their code to be xplat...

That depends. A framework can be cross-platform, perhaps the best example of that being Qt. Others exist as well. In fact, the Yellow Box for Windows is being maintained in at least one form: it's a part of WebObjects. It's possible -though admittedly unlikely- that Quark might license this from Apple.

In fact, there would be one rather large advantage to doing this. Many people -even among the more technologically-savvy communities- think that Cocoa is somehow inherently better than Carbon. This isn't true, of course, but that's almost irrelvant; what really matters is that people think it is. Quark has lost a lot of customers because of their delays in moving Quark to OSX, but their main competitor -InDesign- is a Carbon app, and if I understand things correctly it's not the best Carbon port out there. If Quark can tout the fact that their app is Cocoa, it would help them win back a fair bit of mindshare.

That doesn't, of course, mean that they would pick Cocoa. A lot of companies write their own cross-platform frameworks in-house, and Quark may have one of these already. But we also know that Quark 5.0 is a completely new codebase, which opens up the possibility that they might have a neww framework.

...so there is really zero point in using Cocoa at all. The GUI handling code of an app like Quark XPress is a huge part of the application -- maintaining one codebase for Windows and another for the Mac would be an extremely poor decision on a number of fronts.

The thing is, unless they're using a cross-platform framework, they already have to maintain two GUI codebases, so this is a moot point. The real issue is the backend, which can be cross-platform no matter what language you use.

Again, I don't think it's likely that Quark would switch to Cocoa. But at the same time, if there's one thing I've learned over the bizarre adventure that is my life, it's not to deny the possibilities.

[::maroma::]

I'm a LONG time Quark user. I've recently gotten completely fed up with them. They are a horrible company. Version 5 was the biggest joke in the publishing industry in a long long time. Adding web publishing features to Xpress was the worst thing they could've done. If they don't pull their heads out of their asses for this one, they're doomed.

Besides, by the time Xpress 6 is out (assuming that's what it will be called), InDesign will probably be at v.3. I am more than happy to see Quark die. They've lost my trust and my loyalty with their horrible updates and customer support. I hope they wither away.

[theolein]

Just wanted to add my own two cents as an avid Quark hater: Die, Quark, die!

[Rickster]

My $1/50: if Quark does a Cocoa port in the time frame they're talking about, it'll suck. Xpress is a huge code base -- reimplementing all the platform-specific code would be a truly herculean task. Even taking until the end of 2003 would be too short a time for a developer the size of Quark to do a complete job of it.

Besides, they've already demoed Carbon Xpress a few Macworlds ago (though strangely, like the WWDC '99 Photoshop demo, that Carbon work wasn't very much a part of mainstream development for the next release).

The "completely new code ... not just an upgrade to Carbon APIs" could mean something as simple as "we're doing a new version with new features, not a patch adding Carbon compatibility to the existing version".

And sorry to get off topic, but...

Quake is a poor example -- there was really not much reason to write it in Cocoa to begin with, other than Omni being familiar with Cocoa and not carbon.

Oh, there were plenty of reasons. Foremost among them was that we started our work on Q3 long before Carbon was available for Mac OS X development. But also it means that we have a lot less platform-specific code to maintain and debug.

But yes, it's an extremely poor example. A complex application like Quark has to touch platform-specific high-level APIs (e.g. Cocoa, Carbon, Win32) in a hundred thousand places, whereas your average game just uses an application framework to get itself up and running and pass events down to cross-platform-code. Most of the work done on a game port is around APIs below the level of Carbon/Cocoa differences (such as CoreAudio, OpenGL, HIDManager, and good old BSD system calls).

[voodoo]

I don't doubt that carbon is just as good as cocoa in all respects, if you guys say so. I don't know <anything> about programming.

I have two questions though, in light of this claim:

1. Since cocoa and carbon perform equally good, why did Apple decide to have BOTH in OSX? I don't get it. (obviously, I mean why did Apple have cocoa... duh)

2. Why do carbon apps (even though they are OS X only) always (IMO) feel/look more sucky than their cocoa counterparts? e.g. iTunes, the Finder, GraphicConverter, Office VX, Illustrator10 etc. vs. Chimera, Preview, Mail.app et al.

[spiky_dog]

Apple has Carbon because it's an outgrowth/evolution of the OS 9 API. Cocoa, on the other hand, is derived from the NeXT API. Since OS X is the, er, next version of NeXTSTEP, or however it is supposed to be capitalized, yet is not intended to force all applications to be completely rewritten, it is only logical to keep both Carbon and Cocoa around.

[voodoo]

Originally posted by spiky_dog:
Apple has Carbon because it's an outgrowth/evolution of the OS 9 API. Cocoa, on the other hand, is derived from the NeXT API. Since OS X is the, er, next version of NeXTSTEP, or however it is supposed to be capitalized, yet is not intended to force all applications to be completely rewritten, it is only logical to keep both Carbon and Cocoa around.

Yes. OK. But that is not what the wizkids are saying.

They are saying that a carbon app can do ANYTHING a cocoa app can do, if not better. So in that light, why would Apple keep cocoa in OS X as they are doing?

(meaning, why do they encourage developers to program using cocoa, instead of skipping cocoa alltogether since there is nothin carbon can't do that cocoa can do)

[CharlesS]

Originally posted by voodoo:


Yes. OK. But that is not what the wizkids are saying.

They are saying that a carbon app can do ANYTHING a cocoa app can do, if not better. So in that light, why would Apple keep cocoa in OS X as they are doing?

(meaning, why do they encourage developers to program using cocoa, instead of skipping cocoa alltogether since there is nothin carbon can't do that cocoa can do)

Simple - because although Carbon can do anything Cocoa can do, it is usually a hell of a lot easier to do it with Cocoa, and you can do it much more quickly, because Cocoa takes care of the really boring and mundane details of making all the UI widgets work. In addition, you get a bunch of features "for free" with little or no extra coding. All the stuff that's done for you has been tested extensively and optimized by Apple, so it tends to be cleaner and less buggy than it would be if you did it yourself. This is also why Cocoa applications seem to be cleaner and less "sucky."

Really, try writing some code in both Carbon and Cocoa. You'll understand instantly.

With that said, though, Quark would be insane to throw away all of their existing code base to rewrite it in Cocoa. That would be a lot of extra work, which would really defeat the whole point of Cocoa.

[Terri]

Originally posted by CharlesS:
With that said, though, Quark would be insane to throw away all of their existing code base to rewrite it in Cocoa. That would be a lot of extra work, which would really defeat the whole point of Cocoa.

Would this not be a good idea so future versions will be easier to do?

Also the release would tend to be less buggy?

I'm not a programer so I'm just asking.

[mrmister]

No.

[CharlesS]

Originally posted by Terri:


Would this not be a good idea so future versions will be easier to do?

Not if this version is such a bitch to do that it never gets finished.

Also the release would tend to be less buggy?

If they rewrote the entire code base, it would almost certainly be much more buggy.

[voodoo]

Well Charles, you answered my queastion. There had to be a reason fo Apple to support both at the same time. It now pretty much makes sense to me.

Originally posted by CharlesS:

Really, try writing some code in both Carbon and Cocoa. You'll understand instantly.

Thanks for the advice, but I know about as much programming as I know quantum physics

I get the point though.

[Millennium]

Originally posted by voodoo:
Yes. OK. But that is not what the wizkids are saying.

They are saying that a carbon app can do ANYTHING a cocoa app can do, if not better. So in that light, why would Apple keep cocoa in OS X as they are doing?

(meaning, why do they encourage developers to program using cocoa, instead of skipping cocoa alltogether since there is nothin carbon can't do that cocoa can do)

It's a case of there being More Than One Way To Do It.

Most things are much easier to program in a high-level API such as Cocoa, and Apple prefers this development environment for catering to both new developers, and more experienced ones willing to try out some of Cocoa's really advanced features (there are still a few things you can do in Cocoa that you can't do in Carbon, but that gap is narrowing with every release).

However, there are a few things which are easier to do in a low-level API. There's a saying "In a user-friendly system, simple things are simple, and complicated things are complicated. In a user-hostile system simple things are complicated, and complicated things are simple". In that spirit, Carbon remains a viable -and even important- choice. NeXTStep lacked anything like this, as did Rhapsody. In fact -although David Every might want you to believe otherwise- Copland/Gershwin also lacked anything like Carbon; they were going to use a completely different API and keep something like the Classic environment, but no "upgrade path" for existing codebases.

According to rumors -and this does make a good deal of sense- in some future release of OSX, Carbon and Cocoa will be merged so that Cocoa is written completely on top of Carbon. We can see some evidence of this merging already; in Jaguar, Carbon can actually now create Cocoa windows, while Cocoa is getting access to Carbon's FSRef data structure (this is what Carbon uses to support long filenames while retaining proper file metadata support). I think this is a Good Idea, for many reasons. At that point, though, I hope the Carbon vs. Cocoa argument is finally ended.

[CharlesS]

Originally posted by Millennium:
In Jaguar, Carbon can actually now create Cocoa windows, while Cocoa is getting access to Carbon's FSRef data structure (this is what Carbon uses to support long filenames while retaining proper file metadata support).

I'd like to pick a nit here; Cocoa has always had access to the FSRef structure, because it - and really, most of the Carbon File Manager and Alias Manager stuff, as well as some other things as well - is actually defined in CoreServices.framework, which is linked to by both Carbon and Cocoa. In fact, since 10.1, NSDocument has been using an FSRef, or maybe an alias, or at any rate something that is able to keep track of files when you move them. Try it sometime - open a file with a Cocoa app that uses the NSDocument API (basically any document-based Cocoa app other than TextEdit), make a change, move the file to another folder in the Finder, and save the file in the Cocoa app. It should notice that you've moved the file and ask you what to do.

[smeger]

Originally posted by Millennium:

According to rumors -and this does make a good deal of sense- in some future release of OSX, Carbon and Cocoa will be merged so that Cocoa is written completely on top of Carbon. We can see some evidence of this merging already; in Jaguar, Carbon can actually now create Cocoa windows, while Cocoa is getting access to Carbon's FSRef data structure (this is what Carbon uses to support long filenames while retaining proper file metadata support). I think this is a Good Idea, for many reasons. At that point, though, I hope the Carbon vs. Cocoa argument is finally ended.

The migration of the Carbon widgets to the new HIView system definitely seems to be a harbinger of this change.

[Developer]

Originally posted by CharlesS:

Cocoa has always had access to the FSRef structure.

It's till not using it everywhere. Try to open a file in a deep folder hierarchy (>1024 chars in the path). Pre Jaguar the app would just crash, now the open panel is beeping at you.

[brainchild2b]

I hope not. Quark, and it's engineering team is not reliable. They could go out of business at a moments notice. If your a responsible DPT manager you will work on switching to InDesign or an Adobe Product. It's the smart thing to do, and responsible of you value your job

It's time for quark to give way and die, what once used to be my favorite program... sniff ;-)

Beating a dead horse with a stick will not make him rise up again.

[voodoo]

Oh dear. A Quark basher without a clue. Goes without saying.

There is probably not a single app better than QuarkXPress 4.03 Passport.

Never crashes. Ever. (and that was on OS 8.6) when photoshop 5 and 6 are like a house of cards.

The dimwits at Adobe havn't made a decent app since Illustrator 6. Photoshop 3 was pretty decent too. Since then, Adobe apps have become bloated, mediocre and unstable. Not to mention slow.

Adobe can't get over the fact that Freehand is more popular than its Illustrator, so since version 7 of Illustrator they have been trying to make it become Freehand, thereby destroying their only really good app. Photoshop is in a league of it's own, and is the best image manipulation app out there. Since Photoshop 5, however, things have been going downward FAST for Photoshop. It looks more and more like M$ Word or something, not a professional app. Just to mimic Macromedia, who began incorporating those blasted toolbars in Freehand 8 or something (I'm not much of a Freehand user, so I don't really remember when I saw toolbars first in Freehand ... but they were in Freehand, before they were in Photohop and later Illustrator).

Adobe is going down. They have a plethora of below par apps. One decent and one app they have a monopoly position with. But they are going down. They don't deserve anything better.

Where is Adobe of the 80s? The GOOD Adobe? Darn.

[JLL]

Originally posted by voodoo:
Adobe can't get over the fact that Freehand is more popular than its Illustrator

[iJed]

Originally posted by CheesePuff:


I know you're probably just joking around, but it is, by about 200% in some cases, such as calling a function.

Neither CFM or Mach-O are faster. These are only binary formats and do not effect the main machine code of the program. All speed differences are down to the compiler with the possible exception of application launch time.

[voodoo]

Well, JLL. Are you implying Illustrator is more popular than Freehand? That is not quite the case. Whatever.

Can't you just post whatever you're thinking inseat of a blasted emoticon!?!

[moki]

Originally posted by iJed:


Neither CFM or Mach-O are faster. These are only binary formats and do not effect the main machine code of the program. All speed differences are down to the compiler with the possible exception of application launch time.

Actually, that's not true -- they are both file formats and runtimes. The function lookup overhead for Mach-O is significantly higher than for CFM -- and there are some other differences as well.

In the end, it doesn't matter all that much, because Mach-O got the nod as the file format of choice, so CFM will be supported, but that's about it.

[JLL]

Originally posted by voodoo:
Well, JLL. Are you implying Illustrator is more popular than Freehand? That is not quite the case. Whatever.

Can't you just post whatever you're thinking inseat of a blasted emoticon!?!

When working at a prepress bureau I saw around 5% Freehand files and 95% Illustrator files, and I don't think that anyone would imply that Freehand has a larger market share.

[voodoo]

Originally posted by JLL:


When working at a prepress bureau I saw around 5% Freehand files and 95% Illustrator files, and I don't think that anyone would imply that Freehand has a larger market share.

Ack! It's 82% vs 18%. Memory short cirquit. :o

Never mind.

[tooki]

Without a shadow of a doubt Illustrator has massively more market share than FreeHand.

Too bad, since I like FreeHand better!

tooki

[Mark Tungston]

i know...i was like huh? freehand?

voodoo...sorry but i desagree with you somewhat. i think macromedia has definately made some programs i love but so has adobe. her is a list:

Photoshop
Flash
Illustrator
Fireworks
Dreamweaver
InDesign soon (this program ain't as easy and intuitive as quark but i will leave because quark is clueless. quark 5 is buggy. if a company can't move forward...they've moved backwards)

so it's a mix of both. i like both companies and i have a uncle who works at adobe. i congratulate both companies for bringing their apps to OSX as well.

[godzookie2k]

Silly weirdo Freehand comments aside (sorry, I have big anti-freehand sentiments) I'm going to have to agree with Voodoo here. I hate Quark just as much as the next guy, but there is no better page layout app, for a multiple page document, than Quark 4. (though Quark 3.3 is a damn close second) The frickin program runs like a champ on ANY power pc processor with as low as 32 megs of ram. Yes, 601's and up. And it handles em just fine. Last friday I opened up a 60 some odd page quark document, essentially every editorial content page of our magazine, with a boatload of full bleed 300 dpi images in a blink of an eye. no hiccups, dragging around the beast without a hitch. I *could* try that with mr "I need a G3 with a bucket and a half of ram" Indesign and watch it scroll uber-slow and jittery. As much as I'd LOVE a non-Quark, remotely updated and current DTP application, nothing comes close. InDesign is a great looking program, it has alot of potential, but its bloated, slow, and I've only seen it import about 5 (out of countless) Quark documents without a hitch. Indesign needs speed, it needs to run on lower end hardware, and it needs bulletproof quark importing before I'll ever look at it again.

[Mark Tungston]

godzookie is right

i still use quark in classic because the damn thing is easy to use. even though quark 5 is a step back from quark 4...i still use it because indesign is weird.

indesign 2 looks flashy but it's slow and dare i say it...to many features? i just wish it could handle type easy and concentrate on core page layout functions vs. trying to do all this other bullsh*t i never asked for. i do commend them for some features but they need to make sure the simple ones work first.

(ps. my version of indesign (i paid for it), the undo function doesn't work. is this normal? it can't undo anything and has no history pallete)

[CharlesS]

Originally posted by Mark Tungston:
i know...i was like huh?

Why, did it devour your paper?