--
James Leo Ryan --- Austin, Texas --- talies...@me.com
> Photoshop and Pixelmator are both applications for creating and modifying
> graphic images. Both are rich in features. Photoshop costs $699. Pixelmator
> costs $59. Thats an almost twelvefold difference in price. I'm assuming that
> there are likely some features in Photoshop not present in Pixelmator, but
> for my own graphics processing I have yet to find a deficiency in Pixelmator.
> I'd be interested in other's experiences with the two packages and how they
> feel they compare in features and value.
Photoshop used to be all about two things - 1) A streamlined workflow
for professionals and enthusiasts. 2) Support for high quality brush
strokes and input devices.
Adobe appears to be anti-streamlining now, so #1 is gone. #2 used to be
something that only math wizards could do, but increased processor
speeds allows for brute-force solutions.
--
I won't see Goolge Groups replies because I must filter them as spam
> Photoshop and Pixelmator are both applications for creating and modifying
> graphic images. Both are rich in features. Photoshop costs $699. Pixelmator
> costs $59. Thats an almost twelvefold difference in price.
photoshop elements is a *much* closer match to pixelmator. it is
normally $99, but there is an adobe promo for $59 right now and it's
sometimes bundled free with hardware. it's bogus to compare the full
photoshop with free or inexpensive apps.
> Photoshop and Pixelmator are both applications for creating and modifying
> graphic images. Both are rich in features. Photoshop costs $699. Pixelmator
> costs $59. Thats an almost twelvefold difference in price. I'm assuming that
> there are likely some features in Photoshop not present in Pixelmator, but
> for my own graphics processing I have yet to find a deficiency in Pixelmator.
> I'd be interested in other's experiences with the two packages and how they
> feel they compare in features and value.
I love Pixelmator from the early beta. Almost every update is gift with
new features.
Photoshop is more then ok but only for "pro's" :-)
--
Greets Biagio
> Photoshop and Pixelmator are both applications for creating and modifying
> graphic images. Both are rich in features. Photoshop costs $699. Pixelmator
> costs $59. Thats an almost twelvefold difference in price. I'm assuming that
> there are likely some features in Photoshop not present in Pixelmator, but
> for my own graphics processing I have yet to find a deficiency in Pixelmator.
> I'd be interested in other's experiences with the two packages and how they
> feel they compare in features and value.
What's the chance of a person having enough extensive experience in
both? If you find no deficiencies, then you are good to go! I know I use
Fireworks to export images for the web because I find the PS ways to do
this cumbersome and not *clearly* as good but I would not use my old FW
to retouch picture (especially extensively) because the tools are simply
more cumbersome, not as easy to use as in PS (It is not called
*Photo*shop for nothing!). The point I am making here is that while
there are probably many quite objective differences, much depends on how
you work and what you do. Most people only need fairly simple features
(a bit of colour balance, brightness/contrast, export to jpg, gif, png,
change pixel size).
--
dorayme
I don't have any experiences with Pixelmator, but heard about others'
experiences. The summarise for these are, - if you're common and very
familiar with Photoshop, you won't be satisfied with Pixelmator, and if
you're not familiar with any, Pixelmator will be quite good for a
beginner and semi-experienced person...
But why not use Gimp instead? - It's even free and generally compatible
with Photoshop files...
GIMP 2.6.7 (freeware, req. X11)
Scriptable image app: create, alter & manipulate photos.
http://www.versiontracker.com/dyn/moreinfo/macosx/10322178
cheers, Erik Richard
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Erik Richard Sørensen, Member of ADC, <mac-m...@Mstofanet.dk>
NisusWriter - The Future In Multilingual Text Processing - www.nisus.com
OpenOffice.org - The Modern Productivity Solution - www.openoffice.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> But why not use Gimp instead? - It's even free and generally compatible
> with Photoshop files...
although it's free, it doesn't do anywhere near as much as photoshop.
It certainly depends on which version of Photoshop you compare with. The
latest version of GIMP I'd compare to be quite near to Photosop 7.x. -
And if I recall the features in Pixelmator it's nearer to a Photoshop
5.0-5.5.
Cheers, Erik Richard
> >> But why not use Gimp instead? - It's even free and generally compatible
> >> with Photoshop files...
> >
> > although it's free, it doesn't do anywhere near as much as photoshop.
>
> It certainly depends on which version of Photoshop you compare with. The
> latest version of GIMP I'd compare to be quite near to Photosop 7.x. -
> And if I recall the features in Pixelmator it's nearer to a Photoshop
> 5.0-5.5.
clearly, someone who does not use photoshop very much. the gimp is
comparable to photoshop 3 or 4. it doesn't even have adjustment layers!
the gimp also lacks high bit and is much slower than photoshop.
nospam wrote:
> In article <4b10739e$0$21639$ba62...@nntp02.dk.telia.net>, Erik
It's obviously that you know nothing about GIMP and especially the
newest version 2.6.7.... And your comparison to PhS 3/4 is totally out
of order.:-( - In fact I've just the last hour or so been working with
it to be able to verify what I already have said.
GIMP 2.6.7 can work with multi-layer, add layer, full CMYK, full sRGB +
6 other color management systems, work with up to 40bits color depth,
work with RAW files, up to 4800x4800ppi/in non-interlaced, work with up
to 6 color channels at a time + much, much more - including full image
adjustment like in PhS 7. Apprx. 35 built-in plug-ins (color management
plug-ins not included).
Just for fun I used a RAW file and added 7 more layers and adjusted some
of the color spacing, color room, brightness + contrast. This gave a
remarkable good result.
So why not go and learn what GIMP is and what CIMP can do before you
comment with such useless nonsense....
> >> It certainly depends on which version of Photoshop you compare with. The
> >> latest version of GIMP I'd compare to be quite near to Photosop 7.x. -
> >> And if I recall the features in Pixelmator it's nearer to a Photoshop
> >> 5.0-5.5.
> >
> > clearly, someone who does not use photoshop very much. the gimp is
> > comparable to photoshop 3 or 4. it doesn't even have adjustment layers!
> > the gimp also lacks high bit and is much slower than photoshop.
>
> It's obviously that you know nothing about GIMP and especially the
> newest version 2.6.7.... And your comparison to PhS 3/4 is totally out
> of order.:-( - In fact I've just the last hour or so been working with
> it to be able to verify what I already have said.
>
> GIMP 2.6.7 can work with multi-layer, add layer,
but no adjustment layers, a glaring shortcoming.
> full CMYK,
not according to the documentation. just rgb, greyscale and indexed:
<http://docs.gimp.org/2.6/en/gimp-image-mode.html>
> full sRGB +
it's amusing that they suggest using srgb as a working space. it's
smaller than adobe rgb and much smaller than pro photo rgb (what
lightroom uses).
> 6 other color management systems,
you only need one that works.
> work with up to 40bits color depth,
40 bit color depth?
> work with RAW files,
which is very slow and very primitive, since it's based on dcraw.
> up to 4800x4800ppi/in non-interlaced, work with up
> to 6 color channels at a time
6 color channels in what mode? there's no multichannel, nor is there
lab for that matter. see above link.
> + much, much more - including full image
> adjustment like in PhS 7. Apprx. 35 built-in plug-ins (color management
> plug-ins not included).
only 35?
> In article <4b109513$0$8546$ba62...@nntp06.dk.telia.net>, Erik Richard
> S�rensen <NOS...@NOSPAM.dk> wrote:
> > It's obviously that you know nothing about GIMP and especially the
> > newest version 2.6.7.... And your comparison to PhS 3/4 is totally out
> > of order.:-( - In fact I've just the last hour or so been working with
> > it to be able to verify what I already have said.
> >
> > GIMP 2.6.7 can work with multi-layer, add layer,
>
> but no adjustment layers, a glaring shortcoming.
I must admit, I thought it did.
> > full CMYK,
>
> not according to the documentation. just rgb, greyscale and indexed:
>
> <http://docs.gimp.org/2.6/en/gimp-image-mode.html>
>
> > full sRGB +
>
> it's amusing that they suggest using srgb as a working space. it's
> smaller than adobe rgb and much smaller than pro photo rgb (what
> lightroom uses).
Yes, I tend to work with AdobeRGB myself, sRGB as a default is not the
best option - although it probably does alright for basic needs (web
imaging etc).
> > 6 other color management systems,
>
> you only need one that works.
>
> > work with up to 40bits color depth,
>
> 40 bit color depth?
Yeah, what?
If you're working in Raw format, GIMP does the pre-processing, then
passes on an 8-bit image for post-processing. You can force GIMP to work
in 16-bit mode using GEGL, but it's still very experimental, and just
crashed when I tried it.
There is Cinepaint, but that seems to have come to a stop with
development.
> > work with RAW files,
>
> which is very slow and very primitive, since it's based on dcraw.
And it also strips EXIF data. However, dcraw is a pretty good Raw
processor, and it's far from primitive. Not many other Raw processors
can apply a dark frame at the Raw-processing stage.
> > up to 4800x4800ppi/in non-interlaced, work with up
> > to 6 color channels at a time
>
> 6 color channels in what mode? there's no multichannel, nor is there
> lab for that matter. see above link.
>
> > + much, much more - including full image
> > adjustment like in PhS 7. Apprx. 35 built-in plug-ins (color management
> > plug-ins not included).
>
> only 35?
And you can't easily add more on the Mac version.
I like Gimp, for free it's hard to beat, and if you just need to clean
up a few pics for web viewing, or passing around the family by Email,
then it's OK. Indeed their own FAQ states this.
I tried Pixelmator a little while ago, but didn't see any point of it
over PS Elements. It's about the same price, and doesn't seem to offer
anything better.
I actually find Graphic Converter a useful spare tool for quick image
editing. It is a little clunky and dated looking now, but it works well
and can open and save in more file formats than you can shake a stick
at. It can do things like curves, layers, and use some PS plug-ins
(Noiseware Pro doesn't work, but Noise Ninja does, for example).
--
Andy Hewitt
<http://web.me.com/andrewhewitt1/>
> Andy Hewitt
> <http://web.me.com/andrewhewitt1/>
> I’ve been building this site up over a few years, and now manage it using
> Apple iWeb. It will need modern browsers to function fully.
Pardon me for this catching my eye.
Surely Safari 3.1.2 and iCab latest count as modern enough to carry out
even elementary functions like increasing text size? But not on this
page.
--
dorayme
Ah, I see! It is sort of (?) deliberately done in your CSS (perhaps in
order to hold your design together as if it is a printed page). But
these things come back to bite, *latest* stable Mac FF sensibly takes no
notice of the no-adjust instruction and all hell breaks loose then.
--
dorayme
Nothing of the sort. It's knocked up in iWeb, it appears however iWeb
does it. I'm not a HTML freak, and can only trust in what iWeb does. For
most things it seems to do the job just fine.
Of course layers are adjustable...
>> full CMYK,
>
> not according to the documentation. just rgb, greyscale and indexed:
>
> <http://docs.gimp.org/2.6/en/gimp-image-mode.html>
Yes, I altos noticed the differences between the homepage and the
reality in the app.:-) Look in the prefs settings. Default is sRGB, but
you can choose CMYK if you want to.
>> full sRGB +
>
> it's amusing that they suggest using srgb as a working space. it's
> smaller than adobe rgb and much smaller than pro photo rgb (what
> lightroom uses).
It depends on which color profile (ICC) you choose. I use - and GIMP
uses it as default - the Adobe ICC from CS2, which I also have.
You can also choose to only use sRGB as 'screen flow' and then still
work in CMYK
>> 6 other color management systems,
>
> you only need one that works.
Right, but you can choose the one you best like - or is best for the
apropriate work.
>> work with up to 40bits color depth,
>
> 40 bit color depth?
Yes, fx. with some of Adobes ICC profiles. The default standard in GIMP
is 24bits if you don't change anything in the settings.
>> work with RAW files,
>
> which is very slow and very primitive, since it's based on dcraw.
Not on a MacPro with all 4 kernels enabled in GIMP. Btw. you can select
how many kernels GIMP should use from one to eight...
>> up to 4800x4800ppi/in non-interlaced, work with up
>> to 6 color channels at a time
>
> 6 color channels in what mode? there's no multichannel, nor is there
> lab for that matter. see above link.
Right, there are still differences between the homepage and the app. You
have 6 sliders in the prefs settings for working with up to 6 individual
color channels.
>> + much, much more - including full image
>> adjustment like in PhS 7. Apprx. 35 built-in plug-ins (color management
>> plug-ins not included).
>
> only 35?
That's the default amount.:-) - My next 'excercise' will be to test and
try how many of the many freeware and shareware plugins I have for other
graphics apps that also will work with GIMP.
As a comparison I have also tried the newest version of Cenon. Here is
an app that you can compare with Photoshop 4.x.:-) Cenon isnot near as
enhanced as GIMP - only std. colormanagement RGB + CMYK + Greyscale, no
layer adjustment, no layer adding, no color channel adjustment
etc.etc.... Cenon has one advantage towards GIMP - it is a lot easier
for a real newbie in graphics to use because of it's simplicity...
> > > full sRGB +
> >
> > it's amusing that they suggest using srgb as a working space. it's
> > smaller than adobe rgb and much smaller than pro photo rgb (what
> > lightroom uses).
>
> Yes, I tend to work with AdobeRGB myself, sRGB as a default is not the
> best option - although it probably does alright for basic needs (web
> imaging etc).
that's basically all the gimp is good for - basic stuff.
> > > work with up to 40bits color depth,
> >
> > 40 bit color depth?
>
> Yeah, what?
>
> If you're working in Raw format, GIMP does the pre-processing, then
> passes on an 8-bit image for post-processing. You can force GIMP to work
> in 16-bit mode using GEGL, but it's still very experimental, and just
> crashed when I tried it.
>
> There is Cinepaint, but that seems to have come to a stop with
> development.
right. like i said initially, it doesn't support high bit. most people
aren't going to want to fuss with 'experimental'.
> > > work with RAW files,
> >
> > which is very slow and very primitive, since it's based on dcraw.
>
> And it also strips EXIF data. However, dcraw is a pretty good Raw
> processor, and it's far from primitive. Not many other Raw processors
> can apply a dark frame at the Raw-processing stage.
actually dcraw isn't that great. it's matrices are not as big as some
other raw processors which can cause artifacts, it's slow and it
doesn't offer anywhere near as many options as something like adobe
camera raw.
dark frames are optionally done in the camera and other raw processors
do a much better job of noise reduction, especially adobe camera raw in
the lightroom 3 beta. there are also noise reduction plugins, but those
don't work in the gimp.
> >> GIMP 2.6.7 can work with multi-layer, add layer,
> >
> > but no adjustment layers, a glaring shortcoming.
>
> Of course layers are adjustable...
which isn't what an adjustment layer is. photoshop now has smart
objects which is even more powerful.
as i said before, you don't use photoshop enough to realize what it can
do and that the gimp is nowhere near as capable.
> >> full CMYK,
> >
> > not according to the documentation. just rgb, greyscale and indexed:
> >
> > <http://docs.gimp.org/2.6/en/gimp-image-mode.html>
>
> Yes, I altos noticed the differences between the homepage and the
> reality in the app.:-) Look in the prefs settings. Default is sRGB, but
> you can choose CMYK if you want to.
so you don't understand what that is either. it doesn't support cmyk or
lab and that has little to do with srgb.
<http://wiki.archlinux.org/index.php/CMYK_support_in_The_GIMP>
The GIMP still lacks full CMYK color model support. The ability to
separate and then edit an image in CMYK mode is still a long way down
the list of features to be added (if on the list at all). However,
there is a plugin called Separate that offers a partial solution to the
problem.
> >> work with up to 40bits color depth,
> >
> > 40 bit color depth?
>
> Yes, fx. with some of Adobes ICC profiles. The default standard in GIMP
> is 24bits if you don't change anything in the settings.
what are you talking about? images are 8 or 16 bits per component, or
24 or 48 bits total (assuming 3 channels), not 40 bit. that would be
13.3 bits per component, a very strange amount.
> >> work with RAW files,
> >
> > which is very slow and very primitive, since it's based on dcraw.
>
> Not on a MacPro with all 4 kernels enabled in GIMP. Btw. you can select
> how many kernels GIMP should use from one to eight...
it is much slower than adobe camera raw on the same hardware, and
substantially so. it also doesn't offer anywhere near the feature set.
> > 6 color channels in what mode? there's no multichannel, nor is there
> > lab for that matter. see above link.
>
> Right, there are still differences between the homepage and the app. You
> have 6 sliders in the prefs settings for working with up to 6 individual
> color channels.
why would that be in the preferences, and why doesn't the documentation
match the app?
Most of my image processing tasks are performed on vector-format
technical graphics using Illustrator, with an old copy of Photoshop
Elements 3 kept around to do trivial things like cropping or rescaling
or modifying colors in jpeg images that are going to be imported into
PDF-format Illustrator/Acrobat files.
But occasionally I want to do some amateur touch up of digital camera
derived family or travel photos, and for doing that I haven't found
anything to match just messing with the sliders in the iPhoto Adjust
palette. Just fiddle with these in WYSIWYG fashion until the screen
display looks good, and you're done.
Do any of the other apps discussed here -- including more recent
versions of Photoshop Elements -- have anything comparably simple but
powerful?
Thanks in advance...
> This discussion has been very informative and helpful -- but one
> additional question: Which (if any) of the multiple apps mentioned here
> offers something comparable to the "Adjust" palette in iPhoto?
Perhaps not quite as comprehensive as the "Adjust" tools in iPhoto, with
Preview, which is included with the Mac OS, one can adjust seven
characteristics of a photo, exposure, contrast, saturation, temperature,
tint, sepia, and sharpness. These are all available by selecting "Adjust
Color" from the "Tools" menu in Preview.
> But why not use Gimp instead? - It's even free and generally compatible
> with Photoshop files...
That interface disaster isn't dead yet?
Steve
> Photoshop and Pixelmator are both applications for creating and modifying
> graphic images. Both are rich in features. Photoshop costs $699. Pixelmator
> costs $59. Thats an almost twelvefold difference in price. I'm assuming that
> there are likely some features in Photoshop not present in Pixelmator, but
> for my own graphics processing I have yet to find a deficiency in Pixelmator.
> I'd be interested in other's experiences with the two packages and how they
> feel they compare in features and value.
Pixelmator may be a very nice program, but its developers spammed me a
bunch of times, then smeared me over my complaint on the boards. So I'll
never buy it, and would advise against getting in any kind of business
relationship with them.
Of course, Adobe is also evil, but Adobe is the evil of a massive
corporation. Pixelmator is the personal, targeted kind.
Steve
> dorayme <dorayme...@optusnet.com.au> wrote:
>
> > In article <doraymeRidThis-416...@news.albasani.net>,
> > dorayme <dorayme...@optusnet.com.au> wrote:
> >
> > > In article <1j9vtnr.1vqmqy113at78aN%thewil...@me.com>,
> > > thewil...@me.com (Andy Hewitt) wrote:
> > >
> > > > Andy Hewitt
> > > > <http://web.me.com/andrewhewitt1/>
> > >
> > > > I've been building this site up over a few years, and now manage it
> > > > using
> > > > Apple iWeb. It will need modern browsers to function fully.
> > >
> > > Pardon me for this catching my eye.
> > >
> > > Surely Safari 3.1.2 and iCab latest count as modern enough to carry out
> > > even elementary functions like increasing text size? But not on this
> > > page.
> >
> > Ah, I see! It is sort of (?) deliberately done in your CSS (perhaps in
> > order to hold your design together as if it is a printed page). But
> > these things come back to bite, *latest* stable Mac FF sensibly takes no
> > notice of the no-adjust instruction and all hell breaks loose then.
>
> Nothing of the sort. It's knocked up in iWeb, it appears however iWeb
> does it. I'm not a HTML freak, and can only trust in what iWeb does. For
> most things it seems to do the job just fine.
Yes, I know, was being a touch sarcastic towards your Mac app, not so
much towards you, so take no offence.
It does, like most of these programs, a variably dreadful job. How you
say you trust it, tells me that you are more concerned about how it
looks to you and other average sighted people like yourself rather than
the many folk who would find it more comfortable to be a bit bigger
naturally or when they are tired or when they want to sit back from
their screens to read - I, for example, am big on preferring to slouch
back and break all the ergonomic instructions now and then.
Don't trust the thing too much Andy. These programs are sometimes not
too bad if you can keep a check on them and alter a few things.
--
dorayme
> Of course, Adobe is also evil, but Adobe is the evil of a massive
> corporation. Pixelmator is the personal, targeted kind.
I mean, just look at the name itself, it sounds like something that
could torture... creepy. <g>
--
dorayme
> In article <1j9vtnr.1vqmqy113at78aN%thewil...@me.com>, Andy Hewitt
> <thewil...@me.com> wrote:
>
> > > > full sRGB +
> > >
> > > it's amusing that they suggest using srgb as a working space. it's
> > > smaller than adobe rgb and much smaller than pro photo rgb (what
> > > lightroom uses).
> >
> > Yes, I tend to work with AdobeRGB myself, sRGB as a default is not the
> > best option - although it probably does alright for basic needs (web
> > imaging etc).
>
> that's basically all the gimp is good for - basic stuff.
Yes, a shame really, it looks like it should do so much more, but
there's little that's actually really useful.
[..]
> > If you're working in Raw format, GIMP does the pre-processing, then
> > passes on an 8-bit image for post-processing. You can force GIMP to work
> > in 16-bit mode using GEGL, but it's still very experimental, and just
> > crashed when I tried it.
> >
> > There is Cinepaint, but that seems to have come to a stop with
> > development.
>
> right. like i said initially, it doesn't support high bit. most people
> aren't going to want to fuss with 'experimental'.
Yes, me included. I do test them myself, on copy images, but I wouldn't
use unstable software on my main collection of images.
> > > > work with RAW files,
> > >
> > > which is very slow and very primitive, since it's based on dcraw.
> >
> > And it also strips EXIF data. However, dcraw is a pretty good Raw
> > processor, and it's far from primitive. Not many other Raw processors
> > can apply a dark frame at the Raw-processing stage.
>
> actually dcraw isn't that great. it's matrices are not as big as some
> other raw processors which can cause artifacts, it's slow and it
> doesn't offer anywhere near as many options as something like adobe
> camera raw.
I haven't tried the latest versions of ACR (CS3 was the last I used),
but I would say there's far more options and adjustments in dcraw as it
is in GIMP - that has curves adjustments, and most of the standard
adjustments such as white balance, sharpness, exposure, etc. AFAIK, no
other raw converters have curves adjustment.
> dark frames are optionally done in the camera and other raw processors
> do a much better job of noise reduction, especially adobe camera raw in
> the lightroom 3 beta. there are also noise reduction plugins, but those
> don't work in the gimp.
Not sure I agree with that. All the noise reduction solutions I've tried
have been pretty similar until you do try a dedicated plug-in, or you
can use Lab mode with Gaussian blur. My preference was for NoiseWare
Pro.
Don't get me wrong, I'm not particularly standing up for GIMP here, as
it doesn't work for me either, I just don't see the same reasons as you,
that's all.
> In article <1j9w1m8.1ctt7o91abxw00N%thewil...@me.com>,
> thewil...@me.com (Andy Hewitt) wrote:
>
> > dorayme <dorayme...@optusnet.com.au> wrote:
[..]
> > > Ah, I see! It is sort of (?) deliberately done in your CSS (perhaps in
> > > order to hold your design together as if it is a printed page). But
> > > these things come back to bite, *latest* stable Mac FF sensibly takes no
> > > notice of the no-adjust instruction and all hell breaks loose then.
> >
> > Nothing of the sort. It's knocked up in iWeb, it appears however iWeb
> > does it. I'm not a HTML freak, and can only trust in what iWeb does. For
> > most things it seems to do the job just fine.
>
> Yes, I know, was being a touch sarcastic towards your Mac app, not so
> much towards you, so take no offence.
Yeah, I kinda had an inkling that was what you were at.
> It does, like most of these programs, a variably dreadful job. How you
> say you trust it, tells me that you are more concerned about how it
> looks to you and other average sighted people like yourself rather than
> the many folk who would find it more comfortable to be a bit bigger
> naturally or when they are tired or when they want to sit back from
> their screens to read - I, for example, am big on preferring to slouch
> back and break all the ergonomic instructions now and then.
>
> Don't trust the thing too much Andy. These programs are sometimes not
> too bad if you can keep a check on them and alter a few things.
Don't have much choice really, I could probably knock something up with
HTML code and an editor, with a manual nearby, but that'd take far too
long for me, and take away all the convenience of using iWeb.
If it wasn't iWeb it'd be something else, and like many others I'd have
to trust it to do the job.
It's not just that either, I use it with MobileMe, which makes it a
breeze to update my site, and I use integration with my other iApps too.
I do understand that iWeb doesn't produce a perfect web page, but it's
that, or no site at all. However, if there are any simple solutions to
the problems it does cause, I'm all ears.
iPhoto applies adjustments in a different way to the other editors being
discussed here. All the others take a standard image, apply the
adjustments, and then save the resulting file over the original (unless
you use 'Save as..' of course). That is 'destructive' editing. If it's a
JPG, then data and detail is lost every time you apply adjustments and
save.
iPhoto, along with a few other apps now (Aperture, Lightroom, and one or
two others), uses 'non-destructive' editing, and never touches the
original file (actually it never did, but now it works in a more
efficient way). What it does is apply your adjustments as a set of
parameters in the database. To speed things up, this is saved as a
'Preview' image, alongside the original. This means that when you apply
any adjustments, it never destructs the original, and a fresh Preview is
created if you change the adjustments, so you don't get degredation of
the image.
The adjustment tools in iPhoto, although simple and effective, are also
a little crude IMHO. They are great for producing a family album, or a
web page, but if you want really good image quality, then you need to
look elsewhere. You will probably see that iPhoto produces some very
stunning images, with really vivid colours etc., but start zooming in
and comparing detail with other apps, and you'll see its weakness.
[commenting on iWeb]
> I do understand that iWeb doesn't produce a perfect web page, but it's
> that, or no site at all. However, if there are any simple solutions to the
> problems it does cause, I'm all ears.
An option you might consider is Freeway Express, produced by Softpress in
England. Freeway Express is a WYSIWYG website development application and
requires absolutely no knowledge of HTML and such on the part of the user.
Another plus is that Freeway Express generates fully web compliant code.
Softpress offers a free 30 day trial.
> Pixelmator may be a very nice program, but its developers spammed me a
> bunch of times, then smeared me over my complaint on the boards. So I'll
> never buy it, and would advise against getting in any kind of business
> relationship with them.
I'm sorry to hear of your experience with Pixelmator's team. I've had nothing
but very positive experiences with them and that includes a number of
helpful email exchanges in regards to some "how to dos" I've had.
Seashore puts a reasonably useful GUI frontend on GIMP for basic editing.
> > > And it also strips EXIF data. However, dcraw is a pretty good Raw
> > > processor, and it's far from primitive. Not many other Raw processors
> > > can apply a dark frame at the Raw-processing stage.
> >
> > actually dcraw isn't that great. it's matrices are not as big as some
> > other raw processors which can cause artifacts, it's slow and it
> > doesn't offer anywhere near as many options as something like adobe
> > camera raw.
>
> I haven't tried the latest versions of ACR (CS3 was the last I used),
> but I would say there's far more options and adjustments in dcraw as it
> is in GIMP - that has curves adjustments, and most of the standard
> adjustments such as white balance, sharpness, exposure, etc. AFAIK, no
> other raw converters have curves adjustment.
ufraw/dcraw has the standard controls, but camera raw 4 (which came
with cs3 and is 2 versions old if you count lightroom 3 beta) has much
more, including vibrance, clarity, presets and smart objects. it can
also work on multiple images at the same time and can even be used with
jpeg files for the same workflow, but obviously it will be a bit more
limited than had the original image been raw. camera raw also supports
a few more cameras than dcraw does.
Thanks, but...
One that also integrates with my other software? And wouldn't involve a
complete rebuild of the entire site? AFAIK converting sites between
different editors is a right royal PITA, and a lot of work.
I really meant if there are any *simple* solutions, that maybe a tweak
or two with the iWeb site might solve it.
Fair enough, as I said, I hadn't used later ones. I do use Aperture
myself, and the different between Raw processing and post-processing is
almost transparent (as it is with Lightroom I would expect).
I would have to look at iWeb and what you do. There surely *must* be
controls for stopping some bad things happening. But in general I
suspect not, because the promise is that you can layout your pages like
a print page and then, furiously behind the scenes, iWeb will go to work
to make it happen. Like a medieval magician, it convinces some
observers! But the whole thing is really a horrible sight behind the
scenes, they have to kill many pigs and goats and the carnage and blood
is really not for the squeamish! <g>
--
dorayme
Righto, I've been and tested this now (I very rarely zoom web pages
myself, so have never noticed this), and see what you mean. Hmm.
I ran the page through the W3C checker, and only three errors were found
relating to the Counter. I'll have a look through the font settings to
see if I can find anything relating to changing text size.
> dorayme <dorayme...@optusnet.com.au> wrote:
>
> > In article <1j9wv1m.1x6rwpm128zaltN%thewil...@me.com>,
> > thewil...@me.com (Andy Hewitt) wrote:
> >
> > > I do understand that iWeb doesn't produce a perfect web page, but it's
> > > that, or no site at all. However, if there are any simple solutions to
> > > the problems it does cause, I'm all ears.
> >
> > I would have to look at iWeb and what you do. There surely *must* be
> > controls for stopping some bad things happening. But in general I
> > suspect not, because the promise is that you can layout your pages like
> > a print page and then, furiously behind the scenes, iWeb will go to work
> > to make it happen. Like a medieval magician, it convinces some
> > observers! But the whole thing is really a horrible sight behind the
> > scenes, they have to kill many pigs and goats and the carnage and blood
> > is really not for the squeamish! <g>
>
> Righto, I've been and tested this now (I very rarely zoom web pages
> myself, so have never noticed this), and see what you mean. Hmm.
>
> I ran the page through the W3C checker, and only three errors were found
> relating to the Counter. I'll have a look through the font settings to
> see if I can find anything relating to changing text size.
There is, but be careful. It is:
body {
-webkit-text-size-adjust: none;
}
Perhaps I should have just shut up. But if I had, my enemies would be
far too pleased! <g>
You could ruin the site that works probably well enough for friends and
so on. The problems are deep and fundamental, the whole thing is
stitched together like a home-made boat glued and strung with whatever.
It might make it across if it does not hit *any* stormy seas or
conditions unexpected. Any real time spent on attempt to fix would be
better spent on scrapping and rebuilding with first principles in mind
and a preparedness to sacrifice exact looks for greater functionality
across the whole internet.
Whoever made iWeb was either very naughty (font-sizes in pixels,
line-heights with units, some of the questionable practices guaranteed
to set the scene for *inflexibility*.) or simply machiavellian.
TaliesinSoft's recommendation is possibly better if you do not want to
go all the way and produce with a text editor. (I don't suppose I can
tempt you? Come over to alt.html, you will get all the help you want.)
--
dorayme
As usual you don't read what I was saying. I donot compare GIMP with the
latest versions of Photoshop CS3/4 with GIMP. I compare it - as written
- with PhS 6.x/7.x. And much has happened to PhS since then!
> as i said before, you don't use photoshop enough to realize what it can
> do and that the gimp is nowhere near as capable.
Well... I've only been using Photoshop since ver. 2.5 and am now on CS2,
so I think that I do know quite a lot about using it, though I've never
claimed to be an expert on the Photoshop...
>>>> full CMYK,
>>> not according to the documentation. just rgb, greyscale and indexed:
>>>
>>> <http://docs.gimp.org/2.6/en/gimp-image-mode.html>
>> Yes, I altos noticed the differences between the homepage and the
>> reality in the app.:-) Look in the prefs settings. Default is sRGB, but
>> you can choose CMYK if you want to.
>
> so you don't understand what that is either. it doesn't support cmyk or
> lab and that has little to do with srgb.
>
> <http://wiki.archlinux.org/index.php/CMYK_support_in_The_GIMP>
> The GIMP still lacks full CMYK color model support. The ability to
> separate and then edit an image in CMYK mode is still a long way down
> the list of features to be added (if on the list at all). However,
> there is a plugin called Separate that offers a partial solution to the
> problem.
Sure I do, and I do not need anyh plug-ins. GIMP works just fine with
full CMYK. - And it can even work with 'Alfa channels' - this I didn't
notice yesterday...
>>>> work with up to 40bits color depth,
>>> 40 bit color depth?
>> Yes, fx. with some of Adobes ICC profiles. The default standard in GIMP
>> is 24bits if you don't change anything in the settings.
>
> what are you talking about? images are 8 or 16 bits per component, or
> 24 or 48 bits total (assuming 3 channels), not 40 bit. that would be
> 13.3 bits per component, a very strange amount.
No more strange than it was because it auto-detected my 40bits HP
scanner. deactivating that one, it switched automatically to 32bits.:-)
- Obviously I have activated the TWAIN plug-in without noticing it...
>>>> work with RAW files,
>>> which is very slow and very primitive, since it's based on dcraw.
>> Not on a MacPro with all 4 kernels enabled in GIMP. Btw. you can select
>> how many kernels GIMP should use from one to eight...
>
> it is much slower than adobe camera raw on the same hardware, and
> substantially so. it also doesn't offer anywhere near the feature set.
You keep comparing with latest versions of whatever you suddenly can
come up with. - First it was Photoshop 3.x, then 4.x and now Adobe
Camera RAW, - what'll be the next? - You're simply acting like a fool.:-(!
Btw. I've made more fun with it today by making colorizing a greyscale
picture, adding effects, shading and 4 extra layers etc.. - Exporting
this originally 28kb 128x128pxl now 545,6kb/480x322pxl to .psd was not
measurable...
>>> 6 color channels in what mode? there's no multichannel, nor is there
>>> lab for that matter. see above link.
>> Right, there are still differences between the homepage and the app. You
>> have 6 sliders in the prefs settings for working with up to 6 individual
>> color channels.
>
> why would that be in the preferences, and why doesn't the documentation
> match the app?
You sure don't know GIMP by saying this. Basic settings are always set
in prefs, and then managing of course is from the color menu - exactly
like in any other graphics app - Painter, Freehand, Photoshop, Canvas
etc.etc...
I don't know why documentations and userguide aren't up-to-date, but it
isn't unusual. I've just finished translation of another application. -
Here the documentation and user guide is from the 25th of Febr., while
the app is from 19th of Nov...
Yes, the latest ver. of Photoshop Elements has a more enhanced
colormanaging system than before. - Else I'd recommend you to try to
find a used Adobe CS2 or CS3 and by this gain the full use of the even
more enhanced features in Photoshop.
Else maybe you could use the latest ver. 0.47 of Inkscape, but
unfortunately this app do really lack color management, but it is full
vectorized in the workflow. Also the export facilities are all too limited.
And then of course also GrapæhicConverter can do quite much when using
Photoshop plug-ins. But here you will need a PhS vector plug-in, if GC
should be able to work in full vector mode. And here I'm not sure
whether the 'VectorTools' plug-in for Photoshop 7.x (OS X ver.) would
work with the latest GC versions. The last ver. I used it on was the GC
ver. 4.8.
Also the Canvas 8.x and 9.x do have really fine and enhanced color
management and both versions do also work on SnowLeopard. But you'll
have to find these two as used packages - maybe on eBay or similar places.
Indeed not.:-) - Latest update is from 19th of Aug. this year for Mac OS
X/X11, and if I remember right the latest Win version is from late
September... - I sure admit that the appearance 'interface' isnot the
best. So I do hope that we very soon will have a native OS X beta out...
> >>>> GIMP 2.6.7 can work with multi-layer, add layer,
> >>> but no adjustment layers, a glaring shortcoming.
> >> Of course layers are adjustable...
> >
> > which isn't what an adjustment layer is. photoshop now has smart
> > objects which is even more powerful.
>
> As usual you don't read what I was saying. I donot compare GIMP with the
> latest versions of Photoshop CS3/4 with GIMP. I compare it - as written
> - with PhS 6.x/7.x. And much has happened to PhS since then!
i'm not comparing the gimp with cs3 or cs4. i'm comparing it with
photoshop 4 from 1996, which was when adjustment layers were added.
> > as i said before, you don't use photoshop enough to realize what it can
> > do and that the gimp is nowhere near as capable.
>
> Well... I've only been using Photoshop since ver. 2.5 and am now on CS2,
> so I think that I do know quite a lot about using it, though I've never
> claimed to be an expert on the Photoshop...
you've been using it that long and don't know what an adjustment layer
is??
> >>>> work with RAW files,
> >>> which is very slow and very primitive, since it's based on dcraw.
> >> Not on a MacPro with all 4 kernels enabled in GIMP. Btw. you can select
> >> how many kernels GIMP should use from one to eight...
> >
> > it is much slower than adobe camera raw on the same hardware, and
> > substantially so. it also doesn't offer anywhere near the feature set.
>
> You keep comparing with latest versions of whatever you suddenly can
> come up with. - First it was Photoshop 3.x, then 4.x and now Adobe
> Camera RAW, - what'll be the next? - You're simply acting like a fool.:-(!
camera raw has been around since summer 2002 with photoshop 7, hardly
the latest version.
> Seashore puts a reasonably useful GUI frontend on GIMP for basic editing.
>
> <http://seashore.sourceforge.net/index.php>
Hadn't heard of that yet, will check it out.
Steve
> In article <1j9x5bl.1bc9yl417sw3qnN%thewil...@me.com>,
> thewil...@me.com (Andy Hewitt) wrote:
>
> > dorayme <dorayme...@optusnet.com.au> wrote:
[..]
> > I ran the page through the W3C checker, and only three errors were found
> > relating to the Counter. I'll have a look through the font settings to
> > see if I can find anything relating to changing text size.
>
> There is, but be careful. It is:
>
> body {
> -webkit-text-size-adjust: none;
> }
Righto, I looked for that, and didn't see it. W3C didn't find it as an
error though.
> Perhaps I should have just shut up. But if I had, my enemies would be
> far too pleased! <g>
Yeah, shut up! :-)
> You could ruin the site that works probably well enough for friends and
> so on. The problems are deep and fundamental, the whole thing is
> stitched together like a home-made boat glued and strung with whatever.
> It might make it across if it does not hit *any* stormy seas or
> conditions unexpected. Any real time spent on attempt to fix would be
> better spent on scrapping and rebuilding with first principles in mind
> and a preparedness to sacrifice exact looks for greater functionality
> across the whole internet.
Is that going to work though? Is there a browser that's likely to work
with every site? Or a site that works perfectly with every browser?
Barring keeping it *very* simple, I suspect unlikely is the answer.
> Whoever made iWeb was either very naughty (font-sizes in pixels,
> line-heights with units, some of the questionable practices guaranteed
> to set the scene for *inflexibility*.) or simply machiavellian.
I've had a really good look around the settings and such, and nothing
that seems obvious.
> TaliesinSoft's recommendation is possibly better if you do not want to
> go all the way and produce with a text editor. (I don't suppose I can
> tempt you? Come over to alt.html, you will get all the help you want.)
No, that's too much bother, I probably could knock up a site in HTML
with an editor, but I pay for the convenience of iWeb and MobileMe for a
reason - my priorities are elsewhere.
Put this into context though. I've been using iWeb more or less since it
came out, and you're the first one to comment on this, although now I've
seen it, I do find it annoying :-/. I may do some more digging on this
though.
Cheers.
[responding to dorayme's suggestion in regards to the problems with an iWeb
produced website]
>> TaliesinSoft's recommendation is possibly better if you do not want to go
>> all the way and produce with a text editor. (I don't suppose I can tempt
>> you? Come over to alt.html, you will get all the help you want.)
>
> No, that's too much bother, I probably could knock up a site in HTML with
> an editor, but I pay for the convenience of iWeb and MobileMe for a reason
> - my priorities are elsewhere.
You'd be surprised how quickly on can produce a website with Freeway, a
website that most likely will be error free. My suggestion is to give Freeway
a quick try.
Let's take a look....
Using the W3C Markup Validation Service at <http://validator.w3.org/>
Microsoft's home page at <http://www.microsoft.com/en/us/default.aspx>
295 errors, 26 warnings
Adobe's home page at <http://www.adobe.com/>
20 errors, 7 warnings
Apple's home page at <http://www.apple.com/>
6 errors, 1 warning
Softpress's home page at <http://softpress.com/>
0 errors, 0 warnings
Softpress is the implementor of Freeway and uses their own application to
develop their own website!
> On Sun, 29 Nov 2009 06:07:54 -0600, Andy Hewitt wrote (in article
> <1j9xxw5.1wbc3gq9xa304N%thewil...@me.com>):
>
> [responding to dorayme's suggestion in regards to the problems with an iWeb
> produced website]
>
> >> TaliesinSoft's recommendation is possibly better if you do not want to go
> >> all the way and produce with a text editor. (I don't suppose I can tempt
> >> you? Come over to alt.html, you will get all the help you want.)
> >
> > No, that's too much bother, I probably could knock up a site in HTML with
> > an editor, but I pay for the convenience of iWeb and MobileMe for a reason
> > - my priorities are elsewhere.
>
> You'd be surprised how quickly on can produce a website with Freeway, a
> website that most likely will be error free. My suggestion is to give Freeway
> a quick try.
[..]
I might try the demo, however... For me, it's an expensive replacement -
iLife is about the same price, and I already own iLife. It's an
expensive solution to fix 3 page errors!
I've had a very quick trial of the demo, and find it does have a steeper
learning curve than iWeb, but, I can overcome that. I like using the
templates in iWeb, and being able to change them at any time. I can't
see how to do that in Freeway.
Apart from that, it could be a viable option, although I personally
don't have any problem with the pages iWeb produces, and managing
multiple sites is an absolute breeze.
> Indeed not.:-) - Latest update is from 19th of Aug. this year for Mac OS
> X/X11, and if I remember right the latest Win version is from late
> September... - I sure admit that the appearance 'interface' isnot the
> best. So I do hope that we very soon will have a native OS X beta out...
There was an experimental native OS X build of GIMP 2.6.0, it didn't
really work all that well though. You can still get it here:
<http://gimp-app.sourceforge.net/>
Some folks may also be unaware that GIMP has been undergoing a
substantial redesign recently, which amongst other things means that 2.8
will have more Photoshop-like, single-window interface:
<http://www.mmiworks.net/eng/publications/2009/09/gimp-single-mode.html>
<http://www.chromecode.com/temp/gimp-single-window-mode-in-progress.png>
[commenting on my suggestion to use Freeway Express instead of iWeb in order
to address the problems on an iWeb produced website]
> I might try the demo, however... For me, it's an expensive replacement -
> iLife is about the same price, and I already own iLife. It's an
> expensive solution to fix 3 page errors!
There may be only a small number of reported problems but they are pervasive
throughout the site, affecting every page I've tried.
As an aside, I'm one who routinely when viewing a website in Safari magnify
the presented image of a site to fill the width of my browser window, and
that is usually the full 1650 pixel width of my screen. I visit a great many
sites and the one under discussion here is the only one that exhibits the
falling apart behavior that, as I suggest, is pervasive throughout the site.
> dorayme <dorayme...@optusnet.com.au> wrote:
>
> > In article <1j9x5bl.1bc9yl417sw3qnN%thewil...@me.com>,
> > thewil...@me.com (Andy Hewitt) wrote:
> >
> > > dorayme <dorayme...@optusnet.com.au> wrote:
> [..]
> > > I ran the page through the W3C checker, and only three errors were found
> > > relating to the Counter. I'll have a look through the font settings to
> > > see if I can find anything relating to changing text size.
> >
> > There is, but be careful. It is:
> >
> > body {
> > -webkit-text-size-adjust: none;
> > }
>
> Righto, I looked for that, and didn't see it. W3C didn't find it as an
> error though.
>
Oh, I did not mention it because of any validity or well-formedness
question. You asked about what factors affect text size change. It is
like you asking me why does some site take five minutes to fully load
and I point out that there is this scrap of html:
<img src="http://dorayme.890m.com/alt/justPics/shoalhavenHorses.jpg"
width="700" height="451">
except that the website author has loaded a humongous multi megabyte
version of the image file onto the server and is relying on the browser
to down size it. The fault is not anything about validity, it is about
cause and effect and bad practice.
Analogy: an argument can be lousy but strictly valid.
Another thing but related: when you set font-sizes in pixels, most good
browsers will not stop the user from changing the text size. But Win
Internet Explorer prevents it and it is very frustrating! There is
nothing invalid about it.
So, beware of thinking that all is A OK because some validator ticks it.
...
>
> > You could ruin the site that works probably well enough for friends and
> > so on. The problems are deep and fundamental, the whole thing is
> > stitched together like a home-made boat glued and strung with whatever.
> > It might make it across if it does not hit *any* stormy seas or
> > conditions unexpected. Any real time spent on attempt to fix would be
> > better spent on scrapping and rebuilding with first principles in mind
> > and a preparedness to sacrifice exact looks for greater functionality
> > across the whole internet.
>
> Is that going to work though? Is there a browser that's likely to work
> with every site? Or a site that works perfectly with every browser?
>
> Barring keeping it *very* simple, I suspect unlikely is the answer.
>
I am afraid this is based on quite a nest of misunderstandings. If you
absolutely insist on your pages looking *exactly* the same in all visual
browsers, you probably should be into PDFs. But you can get pretty close
to looking more or less beautifully the same in browsers post IE6, if
you get to know the not inconsiderable members of the set of HTML and
CSS instructions that are widely supported. To cater for IE6, a little
extra knowledge is needed for a few things.
One misunderstanding that some people have is that all those folks out
there are like you. With your eyesight and screen and habits for browser
size or indeed type.
Anyway, large questions!
> > Whoever made iWeb was either very naughty (font-sizes in pixels,
> > line-heights with units, some of the questionable practices guaranteed
> > to set the scene for *inflexibility*.) or simply machiavellian.
>
> I've had a really good look around the settings and such, and nothing
> that seems obvious.
>
Obvious to what? You mean to get rid of the inability to adjust text
size on Safari (for example)? Well, I would not know. But in a text
editor one simply deletes the offending bit(s) I mentioned above.
> > TaliesinSoft's recommendation is possibly better if you do not want to
> > go all the way and produce with a text editor. (I don't suppose I can
> > tempt you? Come over to alt.html, you will get all the help you want.)
>
> No, that's too much bother, I probably could knock up a site in HTML
> with an editor, but I pay for the convenience of iWeb and MobileMe for a
> reason - my priorities are elsewhere.
>
Not any longer. You will now drop all other intersts, divorce your wife,
leave your kids, shoot the dog. And concentrate!
> Put this into context though. I've been using iWeb more or less since it
> came out, and you're the first one to comment on this, although now I've
> seen it, I do find it annoying :-/. I may do some more digging on this
> though.
>
I can understand this. Good luck.
--
dorayme
That's fair enough. But without knowing my circumstances, it's a bit
unfair to keep suggesting I should spend (to me) quite a lot of money to
fix errors which don't really affect me.
At the moment, I could easily go out and buy PhotoShop Elements 8, iWork
09 (I'm still working with '08), and now a new web creator. All of which
would make my computing life better, but each may only give me the
benefit of one particular feature over what I already have to hand.
However, as a widowed single parent, working 3 hours a day, my
priorities are elsewhere, so I quite often just have to 'make do'. My
Mac is a hobby, and I buy what I can for it, but I have to really decide
whether I *need* it first, and how much 'value' something will give me.
I got iLife because it offers more than one function for me, at a price
that is similar to just a single web page creator suggested here.
Remember, I didn't actually ask for this here, it was a comment made
about my site that started it.
Not meaning to sound grumpy, but too often I see replies insisting that
someone *needs* to buy a particular thing, without considering whether
they may be able to afford it - there is often an assumption that we all
have a perfect budget for stuff.
I probably could buy something like Freeway, but would I be sensible to
do so - almost certainly not.
> In article <1j9xxw5.1wbc3gq9xa304N%thewil...@me.com>,
> thewil...@me.com (Andy Hewitt) wrote:
[..]
> > Righto, I looked for that, and didn't see it. W3C didn't find it as an
> > error though.
> >
>
> Oh, I did not mention it because of any validity or well-formedness
> question. You asked about what factors affect text size change. It is
> like you asking me why does some site take five minutes to fully load
> and I point out that there is this scrap of html:
Actually, the question about text size was more a response to the
comments about it being a problem in the first place.
> <img src="http://dorayme.890m.com/alt/justPics/shoalhavenHorses.jpg"
> width="700" height="451">
>
> except that the website author has loaded a humongous multi megabyte
> version of the image file onto the server and is relying on the browser
> to down size it. The fault is not anything about validity, it is about
> cause and effect and bad practice.
For sure, I understand that.
> Analogy: an argument can be lousy but strictly valid.
>
> Another thing but related: when you set font-sizes in pixels, most good
> browsers will not stop the user from changing the text size. But Win
> Internet Explorer prevents it and it is very frustrating! There is
> nothing invalid about it.
To be pedantic, they are set in 'point' sizes, which I believe is
*slightly* different to pixel sizes. However, in this case I suspect the
difference is irrelevant.
> So, beware of thinking that all is A OK because some validator ticks it.
>
> ...
>
> >
> > > You could ruin the site that works probably well enough for friends and
> > > so on. The problems are deep and fundamental, the whole thing is
> > > stitched together like a home-made boat glued and strung with whatever.
> > > It might make it across if it does not hit *any* stormy seas or
> > > conditions unexpected. Any real time spent on attempt to fix would be
> > > better spent on scrapping and rebuilding with first principles in mind
> > > and a preparedness to sacrifice exact looks for greater functionality
> > > across the whole internet.
> >
> > Is that going to work though? Is there a browser that's likely to work
> > with every site? Or a site that works perfectly with every browser?
> >
> > Barring keeping it *very* simple, I suspect unlikely is the answer.
> >
>
> I am afraid this is based on quite a nest of misunderstandings. If you
> absolutely insist on your pages looking *exactly* the same in all visual
> browsers, you probably should be into PDFs. But you can get pretty close
> to looking more or less beautifully the same in browsers post IE6, if
> you get to know the not inconsiderable members of the set of HTML and
> CSS instructions that are widely supported. To cater for IE6, a little
> extra knowledge is needed for a few things.
Not really, I'm not so concerned that it looks 'identical' on all
browsers, just that it's viewable at all (I'm a function-over-form guy).
Hmm, I thought it was suggested I use 'standards compliance', isn't IE
the least standards compliant browser?
> One misunderstanding that some people have is that all those folks out
> there are like you. With your eyesight and screen and habits for browser
> size or indeed type.
No such assumption here, just ignorance of the matter regarding the
fonts, which I note does only occur in Safari, both FireFox and Opera
(all I have tested thus far) zoom the pages correctly.
> Anyway, large questions!
Indeed.
> > > Whoever made iWeb was either very naughty (font-sizes in pixels,
> > > line-heights with units, some of the questionable practices guaranteed
> > > to set the scene for *inflexibility*.) or simply machiavellian.
> >
> > I've had a really good look around the settings and such, and nothing
> > that seems obvious.
> >
>
> Obvious to what? You mean to get rid of the inability to adjust text
> size on Safari (for example)? Well, I would not know. But in a text
> editor one simply deletes the offending bit(s) I mentioned above.
Yes, I have manually edited some bits in the past. Now I don't because
iWeb 09 manages all the FTP'ing, so there's thing I can edit.
> > > TaliesinSoft's recommendation is possibly better if you do not want to
> > > go all the way and produce with a text editor. (I don't suppose I can
> > > tempt you? Come over to alt.html, you will get all the help you want.)
> >
> > No, that's too much bother, I probably could knock up a site in HTML
> > with an editor, but I pay for the convenience of iWeb and MobileMe for a
> > reason - my priorities are elsewhere.
> >
> Not any longer. You will now drop all other intersts, divorce your wife,
> leave your kids, shoot the dog. And concentrate!
Bugger that :-)
> > Put this into context though. I've been using iWeb more or less since it
> > came out, and you're the first one to comment on this, although now I've
> > seen it, I do find it annoying :-/. I may do some more digging on this
> > though.
> >
>
> I can understand this. Good luck.
Looks like I'll need it :-/
[..]
> > > Put this into context though. I've been using iWeb more or less since it
> > > came out, and you're the first one to comment on this, although now I've
> > > seen it, I do find it annoying :-/. I may do some more digging on this
> > > though.
> > >
> >
> > I can understand this. Good luck.
>
> Looks like I'll need it :-/
Well, I'm sure you will be saying this is horrible, but a kind of
workaround has been found in the Apple forums.
Add a shadow to the text (set to minimum opacity), and that does allow
it to be zoomed - abeit a but jagged. I believe this just forces the
text to be a graphic (which is how iWeb saved all the text in the first
release).
> dorayme <dorayme...@optusnet.com.au> wrote:
>
> > In article <1j9xxw5.1wbc3gq9xa304N%thewil...@me.com>,
> > thewil...@me.com (Andy Hewitt) wrote:
>
> >
> > Another thing but related: when you set font-sizes in pixels, most good
> > browsers will not stop the user from changing the text size. But Win
> > Internet Explorer prevents it and it is very frustrating! There is
> > nothing invalid about it.
>
> To be pedantic, they are set in 'point' sizes,
You might have set them in pts, your software outputs it as px. See your:
<http://web.me.com/andrewhewitt1/main_web_site/Home_files/Home.css>
> *slightly* different to pixel sizes. However, in this case I suspect the
> difference is irrelevant.
>
It has no meaning for a screen, so px are used.Don't worry about this,
the point is still it is not a good idea in general to use what is
appropriate for a printed page for the world *wide* web.
> > So, beware of thinking that all is A OK because some validator ticks it.
> >
> > ...
> >
> > >
> > > > You could ruin the site that works probably well enough for friends and
> > > > so on. The problems are deep and fundamental, the whole thing is
> > > > stitched together like a home-made boat glued and strung with whatever.
> > > > It might make it across if it does not hit *any* stormy seas or
> > > > conditions unexpected. Any real time spent on attempt to fix would be
> > > > better spent on scrapping and rebuilding with first principles in mind
> > > > and a preparedness to sacrifice exact looks for greater functionality
> > > > across the whole internet.
> > >
> > > Is that going to work though? Is there a browser that's likely to work
> > > with every site? Or a site that works perfectly with every browser?
> > >
> > > Barring keeping it *very* simple, I suspect unlikely is the answer.
> > >
> >
> > I am afraid this is based on quite a nest of misunderstandings. If you
> > absolutely insist on your pages looking *exactly* the same in all visual
> > browsers, you probably should be into PDFs. But you can get pretty close
> > to looking more or less beautifully the same in browsers post IE6, if
> > you get to know the not inconsiderable members of the set of HTML and
> > CSS instructions that are widely supported. To cater for IE6, a little
> > extra knowledge is needed for a few things.
>
> Not really, I'm not so concerned that it looks 'identical' on all
> browsers, just that it's viewable at all (I'm a function-over-form guy).
>
I would not be bothering if I did not sense a function-over-mere-form
conscience in you. You are worth saving. And this remark convinces me
you need to throw all else to the wind and think alt.html... <g>
> Hmm, I thought it was suggested I use 'standards compliance', isn't IE
> the least standards compliant browser?
>
Sure, but it would be pretty bold to ignore way over half the average
market. IE8 is getting there, 7 is not half as bad and you might for a
personal site simply ignore 6. But the point is that when you make a
webpage, it is nice if it degrades to something that sort of makes the
content obtainable to most people on browsers that are not up to
scratch.
> > One misunderstanding that some people have is that all those folks out
> > there are like you. With your eyesight and screen and habits for browser
> > size or indeed type.
>
> No such assumption here, just ignorance of the matter regarding the
> fonts, which I note does only occur in Safari, both FireFox and Opera
> (all I have tested thus far) zoom the pages correctly.
>
> > Anyway, large questions!
>
> Indeed.
>
--
dorayme
> Not meaning to sound grumpy, but too often I see replies insisting that
> someone *needs* to buy a particular thing, without considering whether
> they may be able to afford it - there is often an assumption that we all
> have a perfect budget for stuff.
>
> I probably could buy something like Freeway, but would I be sensible to
> do so - almost certainly not.
I am a bit sorry I mentioned Freeway (whenever T mentions it, I seem to
be the grumpy about it for reasons not all that dissimilar to those I
give again iWeb. But from what I recall, it was more configurable and
not as naughty. This iWeb twists my internals particularly badly!)
Let me remind you, Andy, I was proposing something for zero cost. All
you need is the free and excellent TextWrangler (it will do for the
html, the css and - but don't worry about this fancy addition - any js
or php).
You know, there is another alternative that I reckon would suit you,
given your personal circumstances (which I respect and sympathise with).
It will cost you nothing again. Get hold of well constructed valid good
practice templates and put in your own materials. You need only
TextWranagler (free classy Mac editor) and a pointer to such templates,
this requires guidance from more experienced people. You can search the
archives of alt.html or better still, pay a visit.
--
dorayme
> In article <1j9ysnm.11u85pn1pl28u1N%thewil...@me.com>,
> thewil...@me.com (Andy Hewitt) wrote:
[..]
> It has no meaning for a screen, so px are used.Don't worry about this,
> the point is still it is not a good idea in general to use what is
> appropriate for a printed page for the world *wide* web.
OK, moving on...
[..]
> > Not really, I'm not so concerned that it looks 'identical' on all
> > browsers, just that it's viewable at all (I'm a function-over-form guy).
> >
> I would not be bothering if I did not sense a function-over-mere-form
> conscience in you. You are worth saving. And this remark convinces me
> you need to throw all else to the wind and think alt.html... <g>
Oh blimey no, I did a fair share with LaTeX for a while, but just find
that I can get quite acceptable results by much easier means.
Oh, I'm also a tiny bit lazy too :-)
> > Hmm, I thought it was suggested I use 'standards compliance', isn't IE
> > the least standards compliant browser?
> >
>
> Sure, but it would be pretty bold to ignore way over half the average
> market. IE8 is getting there, 7 is not half as bad and you might for a
> personal site simply ignore 6. But the point is that when you make a
> webpage, it is nice if it degrades to something that sort of makes the
> content obtainable to most people on browsers that are not up to
> scratch.
Well, I've now just tried the site in IE8, and it all works just fine in
that, so after all that, it's just the WebKit apps that have failed with
this.
I also manage a site for a church, also using iWeb, and I do check that
in IE, as I know a lot of the target audience use IE. I have had to make
a few minor adjustments to make it view OK in that, but overall, it
functions as intended.
Ironically, it seems to only fail in the very app that you'd expect it
to work best in! I even tried the 'Zoom only text', which ends up doing
nothing at all.
> In article <1j9yr7a.1505ymr3kh6rnN%thewil...@me.com>,
> thewil...@me.com (Andy Hewitt) wrote:
>
> > Not meaning to sound grumpy, but too often I see replies insisting that
> > someone *needs* to buy a particular thing, without considering whether
> > they may be able to afford it - there is often an assumption that we all
> > have a perfect budget for stuff.
> >
> > I probably could buy something like Freeway, but would I be sensible to
> > do so - almost certainly not.
>
> I am a bit sorry I mentioned Freeway (whenever T mentions it, I seem to
> be the grumpy about it for reasons not all that dissimilar to those I
> give again iWeb. But from what I recall, it was more configurable and
> not as naughty. This iWeb twists my internals particularly badly!)
Aye, yes, it's more configurable I agree, although that isn't always a
good thing!
> Let me remind you, Andy, I was proposing something for zero cost. All
> you need is the free and excellent TextWrangler (it will do for the
> html, the css and - but don't worry about this fancy addition - any js
> or php).
I do keep a copy of TextWrangler on my system.
> You know, there is another alternative that I reckon would suit you,
> given your personal circumstances (which I respect and sympathise with).
> It will cost you nothing again. Get hold of well constructed valid good
> practice templates and put in your own materials. You need only
> TextWranagler (free classy Mac editor) and a pointer to such templates,
> this requires guidance from more experienced people. You can search the
> archives of alt.html or better still, pay a visit.
Hmm, it's still a much more complicated way than I have now. As my setup
is, it would be extremely difficult to edit the code that iWeb produces,
as the pages aren't created until you perform an upload operation. I
expect I could possibly edit the site directly, but I've no idea how
that would affect iWeb.
A few years ago, I'd not have thought twice about tackling this in such
a way, but now my time is used elsewhere.
I know that iWeb works in a 'black arts' kind of way, and some things
don't work in an ideal manner, but I decided to adapt myself to work
with it that way. For one, to edit the HTML directly, you need to
publish the site to a local folder. Trouble is, that means uploading the
whole site each time, and mine is pretty large (iWeb date stamps all the
files, so it's impossible to check for changed files - I know about it,
so I work around it).
Thing is, I decided to invest in iLife and MobileMe for the sake of
convenience. I can't afford to dump it and move to something else - at
least not until it becomes an economical solution (or my circumstances
change).
What I wouldn't mind paying for (a sensible figure of course) is a way
to configure iWeb better. There are some solutions that work like a
plug-in, but they don't seem to fix any issues that matter at this
point.
> I even tried the 'Zoom only text', which ends up doing
> nothing at all.
This was my very first complaint actually, I did not go into how I had
set my zoom (I prefer just text zoom). It is nice to be able to adjust
just the text and that is one of the main points i was making. That was
the context in which that snippet of css I quoted you about "adjust" was
all about.
--
dorayme
> dorayme <dorayme...@optusnet.com.au> wrote:
>
> > In article <1j9yr7a.1505ymr3kh6rnN%thewil...@me.com>,
> > thewil...@me.com (Andy Hewitt) wrote:
> >
...
> > You know, there is another alternative that I reckon would suit you,
> > given your personal circumstances (which I respect and sympathise with).
> > It will cost you nothing again. Get hold of well constructed valid good
> > practice templates and put in your own materials. You need only
> > TextWranagler (free classy Mac editor) and a pointer to such templates,
> > this requires guidance from more experienced people. You can search the
> > archives of alt.html or better still, pay a visit.
>
> Hmm, it's still a much more complicated way than I have now. As my setup
> is, it would be extremely difficult to edit the code that iWeb produces,
> as the pages aren't created until you perform an upload operation. I
> expect I could possibly edit the site directly, but I've no idea how
> that would affect iWeb.
>
Oh, the idea is that you give up iWeb altogether and simply have your
text files on your disk in a folder (the Sites folder, you have a
powerful web sever on your Mac btw and this is where you need to put the
html files to see them on a home server but this is another issue and
you can simply use the folder as a simple store). You get a free FTP
program, (Cyberduck is great) and simply upload them to a server. There
are even free ones.
You see, the idea is that you piggy back off people who know what they
are doing in templates rather than the iWeb crowd (I know I might be
unfair but I have seen what I have seen! You get cleanish html templates
and decent CSS. You can tweak it if you want or know how or get help
with (and lord there is plenty of help around).
> A few years ago, I'd not have thought twice about tackling this in such
> a way, but now my time is used elsewhere.
>
> I know that iWeb works in a 'black arts' kind of way, and some things
> don't work in an ideal manner, but I decided to adapt myself to work
> with it that way. For one, to edit the HTML directly, you need to
> publish the site to a local folder.
No. You don't have to publish anything or have any server at all to see
how it is going. All you have to do is to grab the html file and drop it
over any open browser window and Bob is your uncle. It gets more
complicated when you need php or any server side scripting but you can
get a *long way without* this.
...
> iLife
>
I honestly don't know what iLife is. Hey Nick, you there? Here's a
program that sounds like it may give you a life and get away from them
thar sheep...
> What I wouldn't mind paying for (a sensible figure of course) is a way
> to configure iWeb better. There are some solutions that work like a
> plug-in, but they don't seem to fix any issues that matter at this
> point.
Up to you. But from where I stand, this is like digging a bigger hole in
order to get out of one... <g>
Remember, it will not cost you any more to at least look for a template
you fancy and at least try one... if you need a hand, scream out.
--
dorayme
> In article <1j9yyf7.b9q0bb1wt48qlN%thewil...@me.com>,
> thewil...@me.com (Andy Hewitt) wrote:
[..]
> > Hmm, it's still a much more complicated way than I have now. As my setup
> > is, it would be extremely difficult to edit the code that iWeb produces,
> > as the pages aren't created until you perform an upload operation. I
> > expect I could possibly edit the site directly, but I've no idea how
> > that would affect iWeb.
> >
> Oh, the idea is that you give up iWeb altogether and simply have your
> text files on your disk in a folder (the Sites folder, you have a
> powerful web sever on your Mac btw and this is where you need to put the
> html files to see them on a home server but this is another issue and
> you can simply use the folder as a simple store). You get a free FTP
> program, (Cyberduck is great) and simply upload them to a server. There
> are even free ones.
Yes, I do know all that. Before iWeb could handle external FTP sites
directly, I had to publish the site to local disk and upload it manually
- I used CyberDuck for that.
However, dumping iWeb is unlikely to happen any time soon. I have three
sites I manage, one of which is much larger than my personal site, I
just do not have the time to rebuild all of these, and manage them
manually.
Right now, if I want to add photos to a page, I simply drag them over
from my Aperture library, and click on 'Upload changes'. Job done.
> You see, the idea is that you piggy back off people who know what they
> are doing in templates rather than the iWeb crowd (I know I might be
> unfair but I have seen what I have seen! You get cleanish html templates
> and decent CSS. You can tweak it if you want or know how or get help
> with (and lord there is plenty of help around).
Righto.
> > A few years ago, I'd not have thought twice about tackling this in such
> > a way, but now my time is used elsewhere.
> >
> > I know that iWeb works in a 'black arts' kind of way, and some things
> > don't work in an ideal manner, but I decided to adapt myself to work
> > with it that way. For one, to edit the HTML directly, you need to
> > publish the site to a local folder.
>
> No. You don't have to publish anything or have any server at all to see
> how it is going. All you have to do is to grab the html file and drop it
> over any open browser window and Bob is your uncle. It gets more
> complicated when you need php or any server side scripting but you can
> get a *long way without* this.
Yes, I do know that too.
> > iLife
> >
> I honestly don't know what iLife is. Hey Nick, you there? Here's a
> program that sounds like it may give you a life and get away from them
> thar sheep...
It's the suite of apps containing iWeb, iPhoto, iMovie, iDVD and
Garageband. Quite good value really.
> > What I wouldn't mind paying for (a sensible figure of course) is a way
> > to configure iWeb better. There are some solutions that work like a
> > plug-in, but they don't seem to fix any issues that matter at this
> > point.
>
> Up to you. But from where I stand, this is like digging a bigger hole in
> order to get out of one... <g>
At the moment, not - there's nothing out there to fix what I need.
> Remember, it will not cost you any more to at least look for a template
> you fancy and at least try one... if you need a hand, scream out.
Righto.....
Of course I could really wind you up, and recreate my site using MS
Word! ;-)
> Of course I could really wind you up, and recreate my site using MS
> Word! ;-)
You know, with Office 97, but not later, the HTML exporter, from what I
recall, does a job that is not all that hard to edit by hand (using a
bit of Search and Replace and GREP) to end up with something not that
indecent... I used to use it a bit for helping me html mark up long
essays and stuff like that... ditching all the classes and CSS
afterwards and cleaning up. Time saving but I can't prove it now.
--
dorayme
> That's fair enough. But without knowing my circumstances, it's a bit
> unfair to keep suggesting I should spend (to me) quite a lot of money to
> fix errors which don't really affect me.
But the fact remains that those errors do affect a great many of those who
would view your site, and they are the ones that count!
> On Sun, 29 Nov 2009 16:44:50 -0600, Andy Hewitt wrote
> (in article <1j9yr7a.1505ymr3kh6rnN%thewil...@me.com>):
>
> > That's fair enough. But without knowing my circumstances, it's a bit
> > unfair to keep suggesting I should spend (to me) quite a lot of money to
> > fix errors which don't really affect me.
>
> But the fact remains that those errors do affect a great many of those who
> would view your site, and they are the ones that count!
I'm not a business you know!
> dorayme <dorayme...@optusnet.com.au> wrote:
>. . .
>
> Yes, I do know all that. Before iWeb could handle external FTP sites
> directly, I had to publish the site to local disk and upload it manually
> - I used CyberDuck for that.
>
> However, dumping iWeb is unlikely to happen any time soon. I have three
> sites I manage, one of which is much larger than my personal site, I
> just do not have the time to rebuild all of these, and manage them
> manually.
>
> Right now, if I want to add photos to a page, I simply drag them over
> from my Aperture library, and click on 'Upload changes'. Job done.
>
>
iWeb is very definitely NOT professional quality. But it offers a quick
way of putting together some fairly nice-looking web pages. Several
times I have used the sequence:
1) Create a site in iWeb.
2) "Publish" the site to a local folder and use something like
PageSpinner (or even a plain text editor) to make relatively minor edits.
3) Use an ftp utility such as CyberDuck to upload the files to a server.
(This is a version of a very old programming paradigm: Use some tool
that generates code rapidly, then edit the result manually to
optimize--or at least improve it in some way--the code.) It is a
reasonably efficient way to produce fairly good results. It's a
compromise. If you are a pro, or an amateur who doesn't mind working
harder, you have more options.
> In article <1j9zjae.rbfjdx7u916bN%thewil...@me.com>,
> thewil...@me.com (Andy Hewitt) wrote:
>
> > dorayme <dorayme...@optusnet.com.au> wrote:
> >. . .
> >
> > Yes, I do know all that. Before iWeb could handle external FTP sites
> > directly, I had to publish the site to local disk and upload it manually
> > - I used CyberDuck for that.
> >
> > However, dumping iWeb is unlikely to happen any time soon. I have three
> > sites I manage, one of which is much larger than my personal site, I
> > just do not have the time to rebuild all of these, and manage them
> > manually.
> >
> > Right now, if I want to add photos to a page, I simply drag them over
> > from my Aperture library, and click on 'Upload changes'. Job done.
> >
> >
>
> iWeb is very definitely NOT professional quality. But it offers a quick
> way of putting together some fairly nice-looking web pages. Several
> times I have used the sequence:
I don't need professional quality.
I doubt it is an efficient way with iWeb because it generates too much
crap and from a fundamentally flawed model. But I would be interested to
see myself wrong on this by seeing any attempts by folk to do what you
have done, namely generate and clean up and ftp... any URLs of your
attempts?
--
dorayme
It seems unfair to compare the GIMP with the full versions of Photoshop,
however old. Six hundred odd dollars ought to buy considerable
superiority over much less expensive applications. How does the GIMP
compare with Photoshop Elements? Pixelmator?
>
> ...
>
--
++====+=====+=====+=====+=====+====+====+=====+=====+=====+=====+====++
||Arnold VICTOR, New York City, i. e., <arvi...@Wearthlink.net> ||
||Arnoldo VIKTORO, Nov-jorkurbo, t. e., <arvi...@Wearthlink.net> ||
||Remove capital letters from e-mail address for correct address/ ||
|| Forigu majusklajn literojn el e-poŝta adreso por ĝusta adreso ||
++====+=====+=====+=====+=====+====+====+=====+=====+=====+=====+====++
> It seems unfair to compare the GIMP with the full versions of Photoshop,
yet people keep doing it.
> however old. Six hundred odd dollars ought to buy considerable
> superiority over much less expensive applications. How does the GIMP
> compare with Photoshop Elements? Pixelmator?
i don't know about pixelmator, but photoshop elements does a lot more
than the gimp does, and faster too. in fact, some of what elements
omits versus the full photoshop are things that the gimp doesn't have
anyway, such as cmyk.
> Erik Richard Sørensen wrote:
> >
> > nospam wrote:
> >> Erik Richard Sørensen <NOS...@NOSPAM.dk> wrote:
> >>>>> ...
> >
> >
> > You sure don't know GIMP by saying this. Basic settings are always set
> > in prefs, and then managing of course is from the color menu - exactly
> > like in any other graphics app - Painter, Freehand, Photoshop, Canvas
> > etc.etc...
>
>
> It seems unfair to compare the GIMP with the full versions of Photoshop,
> however old. Six hundred odd dollars ought to buy considerable
> superiority over much less expensive applications. How does the GIMP
> compare with Photoshop Elements? Pixelmator?
>
Sorry, but it seems quite fair to compare the GIMP of taday with, say,
Photoshop 7. At this time, Photoshop 7 can be acquired at places that
sell used software (such as some used bookstores here in Spokane) for
as little as $30 and on eBay for prices of less than $10, In fact,
Photoshop CS2 (i.e. PS 9) is frequently selling for less than $35.
A comparison to CS4 would be unfair, but not with older versions going
for nominal amounts, IMO.
--
Spenser
Maybe, maybe not. Don't forget that when working with opensource, many,
many people can and do contribute with their code and experience. - Just
think of OpenOffice. It's exact same situation - M$ Office cost a lot,
OpenOffice is free and in my opinion far much better and more compatible
than most parts in MSO...
And as written many times now, I donot compare GIMP with the latest
versions of Photoshop, but something near the ver. 6.x-7.x. Much has
happened to Photoshop in CS2 to CS4...
> How does the GIMP compare with
> Photoshop Elements? Pixelmator?
The latest version of Photoshop Elements I've used is the ver. 4.0 and I
wasn't impressed of that one, if you're used to use keyboard commands
with Photoshop. Shortcuts aren't always the same as you expect.
But one thing that I do know is that GIMP 2.6.7 works fine also in
connection with Photoshop CS2, which is the latest version that I have.
I have also now tried something that I never have tried before. I have
inserted some of the GIMP files saved as .psd into some wordprocessors
that absolutely donot like non-legacy formats like AppleWorks,
NisusWriter Pro, Word 2008(Mac) and 2003(Win). The GIMP files are shown
100% correct both in color and sizes in these wordprocessors.
I could have understood the hazzling, if I had taken the Cenon and
compared this one with the Photoshop versions that I compared GIMP with.
Though Cenon also is built on the same engine as GIMP.app, there are so
many differences between these two apps. Where GIMP is real fine, Cenon
is somewhat poor - especially in the color management system as well as
handling layers. Also resizing in Cenon can be somewhat painful towards
GIMP. And where I compare GIMP with Photoshop 6.x-7.x, I'd put Cenon
down near Photoshop 3.0-3.5...
cheers, Erik Richard
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Erik Richard Sørensen, Member of ADC, <mac-m...@Mstofanet.dk>
NisusWriter - The Future In Multilingual Text Processing - www.nisus.com
OpenOffice.org - The Modern Productivity Solution - www.openoffice.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > It seems unfair to compare the GIMP with the full versions of Photoshop,
> > however old. Six hundred odd dollars ought to buy considerable
> > superiority over much less expensive applications.
>
> Maybe, maybe not. Don't forget that when working with opensource, many,
> many people can and do contribute with their code and experience.
most people just want to edit photos, not write code.
> - Just
> think of OpenOffice. It's exact same situation - M$ Office cost a lot,
> OpenOffice is free and in my opinion far much better and more compatible
> than most parts in MSO...
that's a neat trick, more compatible than the original. how does that
work? the original, by definition, is 100% compatible.
You keep saying that, but still this isnot true. GIMP does have CMYK! -
How on earth can a GIMP CMYK file saved as a .psd and then opened in
Photoshop turn up as a full editable CMYK file with CMYK profile active,
though I've set my PhS CS2 to use RGB as screen workflow and the ICC to
be RGB as well?
And regarding the speed of GIMP. I wouldn't call it 'slow' to open a 2gb
file in less than 2 secs. from scratch ready to use! - i.e. X11 and GIMP
are both quit. Having both X11 and GIMP open in the background an apprx.
5-6gb file will open in apprx. 1 sec.. Photoshop CS/CS2 are far much
slower opening from scratch, but near same time if in background.
Cheers, Erik Richard
> And regarding the speed of GIMP. I wouldn't call it 'slow' to open a 2gb
> file in less than 2 secs. from scratch ready to use! - i.e. X11 and GIMP
> are both quit. Having both X11 and GIMP open in the background an apprx.
> 5-6gb file will open in apprx. 1 sec.. Photoshop CS/CS2 are far much
> slower opening from scratch, but near same time if in background.
who said anything about opening a file? i'm talking about various
actions, such as setting the white/black point in levels, or just
levels itself. last time i tried white/black point, it was about 10
seconds in the gimp versus a fraction of a second in photoshop with a 3
megapixel image on the exact same hardware. also, adjusting levels,
curves, etc. is not real time in the gimp and there's also a lot of
flicker when scrolling.
Precisely! The more contributers, the better application and the more
people want to use it. And the better the contributer's code is, the
better the app will be, and then even more people want to use it...
>> - Just think of OpenOffice. It's exact same situation - M$ Office cost
>> a lot, OpenOffice is free and in my opinion far much better and more
>> compatible than most parts in MSO...
>
> that's a neat trick, more compatible than the original. how does that
> work? the original, by definition, is 100% compatible.
Well... How and when has the MSO been able to read, write or convert to
and from an ODF/ODT file? - NEVER! - And it won't be either with that
piece of crab called 'Open XML Converter'.:-(! - And don't forget that
the ODF format now is an ISO standard, which none of the MS formats are.
- And btw. the MSO isn't even capable of reading/converting it's own
files between the Mac and Windows versions.
- Try to open a RTFD file made on a Mac in MSO2003/2007? - CRASH!
- Try to open a XML file made with MSO2007 in MSO2004/2008 on a Mac? -
CRASH!
- Try to open a simple and common RTF file made on a Mac MSO2004/2008,
opened in MSO2007(Win), saved, and again opened in MSO2004(Mac)? - CRASH!
- Try to open a common and simple .doc file made on MSO2000-2007(Win) on
a Mac with MSO X, 2004, 2008, or a .doc file made with MSO X, 2004 or
2008 on a Mac and open it in MSO2000-2007(Win)? - where the hack are the
formattings and fonts? GONE!
Do you call this 'compatibility'?
Now try to open any ODF file made with NeoOffice Mac, OpenOffice Mac,
Win or Linux or the StarOffice Mac/Win/Linux on any other OpenOffice or
StarOffice or NeoOffice and you will see that the files are 100%
identical in any version and system, no loss of formatting, fonts,
sizes, setups etc. - That's what I call 'compatibility!
Cheers, Erik Richard
> It seems unfair to compare the GIMP with the full versions of Photoshop,
> however old.
I don't think it is, really, when you consider the amount of development
hours that have gone into GIMP. That number may still fall short of
Photoshop's (especially as PS had a 6 year head start), but it's
probably comparable to plenty of other software you'd pay hundreds of
dollars for.
> And regarding the speed of GIMP. I wouldn't call it 'slow' to open a 2gb
> file in less than 2 secs. from scratch ready to use! - i.e. X11 and GIMP
> are both quit.
Neither would I, but I've never seen X11 and GIMP start up in less than
30 seconds on my Macbook Pro. What's the secret?
Maybe a MacPro QuadCore 2,66ghz with 9gb physical RAM, but 'only'
running 10.5.8 with latest updates. - All 4 kernels enabled in GIMP...
One speaks of launching the app; the other, opening a file.....
--
john mcwilliams
All the better for the GIMP if it can withstand such comparison; I only
meant to imply that expectations are for comparison with Photoshop
Elements or Pixelmator, given that the high price of Photoshop buys a
lot of professional development. I also didn't mean to imply backward
comparison with earlier versions of Photoshop, only with contemporary
versions. Of course that leaves the GIMP out of the comparison running
for Photoshop's first six years.
I am a great admirer of much open source software and run Ubuntu-for-Mac
in its own partition, to say nothing of Open Office, NeoOffice, and
Porticus. I first got interested when I noticed vi and emacs in the
kernel of an early version of Mac OS X and installed Debian in X11. I do
find that open source software generally has rough edges.