Opening other graphic formats

[gregingero]

I note, quite rightly, there is discussion about the ability to open Freehand files. Not sure if this has been mplemented. Doesn't look like it. I'd also like to ask that Canvas files could be opened, too. I have most of my work on this (and I have to keep going back two systems to open them). Can I send some files for viewing? If so, where to?   

[000]

Freehand files can be opened. In case you stumble upon a file that doesn't work properly, I'd recommend either posting it here or sending it to Serif so they can investigate the file and improve / enhance their import filters.

 

In regard of Canvas, you might want to try exporting your documents as PDF and opening them in Affinity Designer -- most drawings should transfer nicely. In case you have used Canvas for page layout, you might want to wait until multippage features are implemented in Designer, respectively until Publisher is released next year.

[Andy Somerfield]

Freehand import is in (versions 10 through MX - FH9 import is on the list to be done soon) - only trouble is, FH often saves files with no extension (no idea why they did that) - which we refuse to open!

 

Rename your files .fh11 and they should open..

 

Thanks,

 

AndyS

[davidpwrmc]

@AndyS.... regarding why FreeHand would save files with no extension....my guess for that would be that FreeHand "grew up" in the time when MacOS did not require extensions on the ends of filenames and so that could be why the application didn't bother to save extensions on files by default. 

 

The original way that Mac files were set up meant that they had two forks:  a data fork....and a resource fork.  The guts of the file were contained in the data fork, while the resource fork contained other info including references as to what application the file belonged to.  Thus, when the Mac OS Finder was asked to open a file, it would simply take a look at the file's resource fork, find out what application the file was made in, and thus open the appropriate application.  As a result of this setup, MacOS files never did require an extension on the filename....unlike Windows, which expected a file extension on EVERY filename.  I am assuming that Windows files had ONLY a data fork and that was it. 

 

With the advent of Mac OS X, it seems that file extensions have become more prevalent and desired, but my understanding is that, even in OS X, the files still have those 2 forks.  So, files can still be able to be saved without an extension on the filename even under OS X. 

 

Anyway, that's my guess as to why FreeHand was doing what it was doing extension-wise.  When FreeHand was being developed, extensions on filenames were just not needed in MacOS.

 

   - David   

[davidpwrmc]

One other thing regarding "extensions" as related to Mac OS.....in the days BEFORE Mac OS X, there was the "classic Mac OS" (i.e. all versions of Mac OS from Version 1.0 to Version 9.2.2).  In the classic Mac OS, there was another use of the word "extensions".  In that era, "extensions" referenced bits of software that would load at startup and which, when loaded, added additional capabilities to Mac OS (in essence, "extending" Mac OS). There were all manner of extensions available for Mac OS back then....some from Apple, and many of them from 3rd party developers. 

 

As the extensions loaded at startup, thumbnail icons representing each extension would also appear onscreen starting at the lower left corner of the monitor screen.  They would display, one by one, going from left to right across the bottom of the screen.  I always referred to this as the "march of the icons".  Extensions had the ability to add many different capabilities....however, they also added complexity and the possibility of compatibility problems.  Thus, there came about the need to do troubleshooting when such incompatibilities occurred.  "Extension conflicts" thus became part of the language that just about every Mac user was familiar with back then.   

 

Anyway, I just wanted to mention this reference to "extensions" as it relates to earlier iterations of Mac OS, since this is what Mac users thought of whenever anyone mentioned extensions.  Of course, for those using Windows, "extensions" were always referencing the letters following the dot near the end of the filename such as ".doc"....something that Mac users had no direct experience with during that earlier era of Mac OS.  

 

Fyi.   

 

    - David  

[Andy Somerfield]

That's interesting David - my first experiences with OS X were circa 2004, so I guess I missed out on all this :)

 

AndyS

[davidpwrmc]

@AndyS....

 

Yep...you missed out on "the good old days" of Mac OS.   To be sure, some Mac users also referred to that era as "the bad old days" since the original Mac OS had its limitations and crankiness.  

 

In the days after The Steve (aka Steve Jobs) had left Apple (i.e. back around 1987 or thereabouts), Apple was searching for a way to upgrade the Mac OS.  They spent mass quantities of money (I heard estimates of literally a billion dollars) trying to do R&D to make the Mac OS modern, but after all that effort (and money) there was no joy.  There was no way to put modern services (things you would expect from a modern industrial-strength operating system...such as pre-emptive multi-tasking) into the creaky old codebase of the classic Mac OS (the old Mac OS used something called co-operative multi-tasking).  So, Apple began casting around for a new OS to make their own.  

 

For a period of time, they were considering buying BeOS (developed by Jean-Louis Gassee, Apple's former head of product development), but that didn't work out so Apple kept looking.  They ended up settling on the NeXT OS from..... :::drumroll:::: ....Steve Jobs' "next" company and the rest, as they say, was history.  The Steve came back to Apple as a consultant, and ended up as their iCEO.  And the NeXTStep software, which was codenamed Rhapsody for development as Mac OS X, became the OS that Apple uses to this day. 

 

Here is a link to Gassee talking about BeOS and NextStep from back then:  

http://9to5mac.com/2011/11/11/gassee-thank-god-apple-chose-steve-jobss-next-over-my-beos/

 

Anyway, with all of the above, you can see why FreeHand didn't bother to automatically add "extensions" to filenames....it just wasn't something that was used in the old Mac OS.  We didn't need it back then.  

 

Those were the days!      ;)

 

   - David   

[Andy Somerfield]

Agreed,

 

I'm familiar with the NeXT transition - it was, imo, the best decision Apple made before Jobs returned - and one which continues to serve them well to this day. Recent developments are also promising - people don't seem to realise the importance of Swift as a language - native compilation, just like C / C++, avoiding common C / C++ pitfalls. There are many good reasons why performance guys like us still use C++. If it gains traction, it will be a game changer. And no support for exceptions - which I personally think is one of its best features. Often, with languages, less is more..

 

A

[rui_mac]

I'm a Mac user since 1989 and yes, I can attest about that resource-fork/data-fork stuff that still exists.

That didn't only freed files from requiring extensions as it make application/file paths obsolete.

Once an application was "installed" (usually just copied from a floppy to the HD), it could be placed anywhere, move, zipped, the original deleted and the unzipped file would recreate the application again, the folder structure completely changed and/or renamed and everything JUST WORKED.

Many Mac applications still work that way, today. Affinity does :-)

Trying to do the same on a Windows machine is a recipe for an headache ;-)

[davidpwrmc]

@AndyS....

 

I've never been a "programmer" myself....just an observer of events on that side of things.  The closest I got to programming was having to do code for old Atex typesetting machines while I was working as a graphic designer in a major newspaper marketing department (in Atlanta GA) back in the early to mid 1980s.  Those systems had the black screens with the green pixellated onscreen fonts and was code-only....no GUI or WYSIWYG.   

 

However, these days I am considering getting into developing apps for iOS, and just as I was getting set to try to learn Objective C, Apple suddenly unleashes their new "Swift" programming language.  Would it be accurate to presume that Swift is all I would need to concentrate on?  Or would there be other ancillary stuff I should also become acquainted with?  

 

@ rui_mac....

 

Yes, it was very handy to be able to move files around with relative impunity on the old Mac OS.  The most extreme version of that that I can think of was my routine of keeping a "fresh" copy of the "System" and "Finder" files in separate standby folders so that when the current System or Finder files got corrupted, I could just toss one (or both) into the Trash, copy new versions of those files into the System Folder from my standby folders, reboot the Mac, and continue on with a "fresh" System folder.   Now, obviously it would be better to re-install the System files/folder from an installer file, but for those situations where time was short, that routine of substituting fresh System and/or Finder files into the System Folder worked like a charm.  

 

I think if you tried that today with Mac OS X, a small mushroom cloud would probably rise out of the Mac!      :o ;)

 

   - David   

[Andy Somerfield]

Well,

 

Writing for iOS you have two choices:

 

1.) Objective-C (well understood, good books on it, plenty of sample code on the internet - but has a number of oddities - memory management being one. If you need to write very fast code, you cannot really use Objective-C - you would need to learn regular C or C++ too).

 

2.) Swift (brand new, benefits from being designed now, when we know much more about what makes a good language! Good documentation from Apple, but no other real material available yet. No need to learn C or C++ even for writing fast code).

 

It's worth noting that you can mix and match - projects can contain a mixture of Swift, Objective-C, C++ and C. The only caveat being that Swift cannot talk to C++ (which is something of a shame for us here).

 

Thanks,

 

AndyS

[rui_mac]

Well, David, that is because MacOS is, in fact, unix ;-)

Even a small mushroom cloud would rise from... lets say, the head of a user that, incidentally or on purpose deleted or manual changes the name of the user folder.

Everything is much more sensitive now.

 

And yes, I still remember that creating, copying and managing the System folder was so much easier. We just had to make sure that the Finder file and System files were in the same folder so that it got "blessed". Oh, "blessing" a folder... memories :-)

[CouponPages]

I've been using Fireworks long before Adobe screwed it up then ditched it, so I have a lot of art in Fireworks PNG files.  While I realize I can load PNG files directly, everything is flattened.

 

My only workaround is keeping Fireworks open at the same time, so I can cut/paste individual elements.  Vector object from Fireworks are still converted to bitmaps, but I can at least pick individual elements and scale them before I paste.

 

In my case, I have a bunch of commonly used vector based things like my logos that I need to layer into my work, so my main objective is finding some method to get those key elements into Affinity.  If direct support for PNG files with vectors isn't coming soon, I'm open to alternatives just to get my logos converted.

 

I tried things like exporting them into an intermediary file like AI, but I see there is limited support for that too.  Is there a file format that I can export from Fireworks, that can be imported into Affinity?

 

For me, once I get my library of logos and common elements into an Affinity compatible format, I can cut the cord on Fireworks for good.  I've been using it for a long time, but it's time I move on.

[v_kyr]

Yeah down the memory lane ... once upon a time when I worked for a NeXTcomputer subsidiary (those days called a NeXTcenter) what is known today as Freehand was initially called Altsys Virtuoso. Altsys was once the creator of that fine peace of vector graphics software, which they later licensed to Aldus. Aldus in turn then renamed Virtuoso into Freehand and so on ... you can just read this to see the whole story!

 

Virtuoso (aka Freehand) was a nice vector software under NeXTstep/OpenStep, even it was much more expensive in contrast to Appsoft Draw, Stone Design Create and some other promising vector oriented software for NeXTstep. Adobe with it's Illustrator followed some time later after Virtuoso, but when it came out got fast popular under NeXTstep/OpenStep. All in all those former days a lot of conceptual new and very creative software was build, due to NeXT's neat DisplayPostscript and ObjC programming API capabilities. - Well todays Mac users still do live in that slightly modernized and inherited NeXtstep ecosystem! :)

[Peter Werner]

I'm not sure about the NeXT being the best choice for Apple at the time – except for the obvious part about getting Steve Jobs back.

 

As davidpwrmc pointed out, at the time, there also was some talk about them buying Be and using BeOS as the foundation for the new MacOS. BeOS had a much more modern architecture, database-based file system that basically had the Spotlight index built-in before Spotlight existed, was completely multi-threaded from the ground up so applications would never lock up (pretty much unheard of in the late 90ies), booted in seconds, and had a clean and really easy to use native C++ API and could play multiple videos in parallel and still render a few OpenGL windows at the same time, which at that time was exclusively the domain of insanely expensive SGI workstations. There were even versions of Steinberg Cubase, Maxon Cinema 4D as well as a few great native programs for the platform before Be was more or less forced out of the market by Microsoft.

 

If you compare that to the current macOS, which is actually a fairly strange combination of ancient Unix, classic Mac legacy, the NeXT Step APIs, completely new Apple tech, and all sorts of other bits and pieces, BeOS actually was in many ways a much more modern operating system than macOS is even today.

 

There are even a few guys who basically re-programmed the entire BeOS from scratch as open source because so many people thought it was such a shame that it went away. I think they are still going at it steadily under the name Haiku, I even saw something about an upcoming Beta release. However, I haven't tried it yet.

 

By the way, the classic OS X Creator and FileType fields are still around even on macOS and there are APIs in place to read and write them (NSFileManager's setAttributes command with NSFileHFSTypeCode and NSFileHFSCreatorCode if I recall correctly). 

 

In theory, you could use that to recognize FreeHand files without extensions that were saved on classic MacOS, as long as the file's resource fork was preserved.

[v_kyr]

Well those former days there were of course always also contrary opinions about which OS might have been the better choice for Apple, but IMO the NeXT system was an overall much more complete and functional system than BeOS.

 

NeXTstep/OpenStep those days was a full working BSD Unix based system with a Mach kernel. It offered DisplayPostscript (real WYSIWYG) and thus direct prerendered Postscript printing, had powerful OO programing APIs due to ObjC and reusable objects, which allowed to build dynamic things like the InterfaceBuilder etc. The later was something programers (like me) had dreamed of those days. It also offered compiling/running fat binaries for the four supported architectures.

 

Further NeXTstep had a strong application base, things like Mathematica, RenderMan, Lotus Improv, Lighthouse Design Diagram! + Concurrence + Quantrix + OpenWrite, Altsys Virtuoso, Stone Design Create + DataPhile, WWW, OmniWeb, WebObjects, WriteUp, Pages, WordPerfect, FrameMaker, Sybase, Eiffel, Smalltalk, ... and so on. Some of those applications offered real trailblaizing new improved usability concepts those days and enhanced a users productivity a lot. - For BeOS there wasn't much available in contrast (only some demo apps) and if I remember correctly it even couldn't print those days.

 

So even I might sound a little bit biased here, since in the past I worked some time in the NeXT domain, I remember that BeOS wasn't right there and in contrast a little bit let's say incomplete, for the money Apple had to pay.

 

About getting Steve Jobs back, well that's another theme ... since most NeXT users in those former times thought they had been sold (...to be Stev'ed)! ;)