On Thu, 2002-01-31 at 19:01, Paul M Foster wrote:
> On Thu, Jan 31, 2002 at 05:31:18PM -0500, Derek Glidden wrote:
>
> >
> > Hi Robin,
> > Just read your "Why _not_ to use Linux" article and had just a couple of
> > comments/questions I wanted to pose, but not in the feedback/comments
> > since that would just be a waste of time... (which goes to show that I
> > fully agree with at least the latter part of your story. :)
> >
> > Other than proper CMYK colorspace support, what do you see as glaring
> > drawbacks in using "The Gimp" for full-on DTP?
> >
>
> Full on DTP? I'm not sure if you mean what I mean when I say that. Since
> I'm in that business, I can say for certain that the Gimp is not up to
> the task, and never should be. Nancy (who does the actual DTP for our
> company) could tell you more about what's involved. If you're going to
> do real DTP, not even MS Publisher will do. You need PageMaker or Quark
> (or maybe InDesign, but the jury's still out on that one). There are all
> kinds of little things that make a page layout package useful or
> useless. You may be able to torture a package into doing some of this
> stuff, but if it's not simple to do without a lot of rigamarole, it's
> not worth it. You can do DTP with MS Pub, but not professionally.
I suppose I meant more along the lines of "professional print
graphics." I know Gimp isn't DTP by any stretch, but the biggest
problem with using it to do any sort of print work is that it just
doesn't do CMYK. I was wondering if there were any other major
showstoppers, because that's really the only "big showstopper" I've ever
heard anyone complain about, but at least according to Robin, that's the
big one.
Hopefully, the Gimp crew can overcome that in some upcoming version and
then there will be no reason not to. If I could find the reference to a
Gimp whitepaper I read some time ago, that came from some kind of Gimp
developer's conference, there were a LOT of things in the works like
having a fully-modular core engine that could handle ANY colorspace you
could throw at it by writing a new plugin (having a modular core engine
is really cool) and the neatest thing I recall was that the engine was
going to have this concept of "action vectors" (I don't remember what
they called them exactly) where every action you took on an image would
be kept in something like Photoshop's action list, only EVERYTHING would
qualify to stay in that list, and you could "hide" any action in the way
you can hide a layer now, and rearrange the order the actions would
occur and have the core engine re-render the image from the beginning
with the new action list. It was very cool.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/usr/bin/perl -w
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map
{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;
$t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)
[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join
"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*
8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}
print+x"C*",@a}';s/x/pack+/g;eval
usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \
| extract_mpeg2 | mpeg2dec -
http://www.cs.cmu.edu/~dst/DeCSS/Gallery/
http://www.eff.org/ http://www.anti-dmca.org/
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:37:17 EDT