Menu
▾
▴
gimp-print-devel
|
From: Robert L K. <rl...@al...> - 2000-06-22 23:01:48
|
Date: Thu, 22 Jun 2000 23:18:56 +0100 From: Ralph Corderoy <ra...@in...> > > I'd call it "1440x720 with 4x vertical oversampling". A bit wordy, > > but it's clear what it is. > > That's a bit verbose to fit in the menu, and that's also a name aimed > at people who understand the technical details. I want a name that > makes sense to people who *don't* have the technical background to > understand this, but. That's a tough requirement. They probably need to learn about resolutions. Otherwise, how about `1st Class', `2nd Class'... or Bestest, Best, Better, Good... :-) They already know from their manual that the printer supports 360x360, 720x720, and 1440x720, and that they get better as the numbers go higher. Oversampling is a technical term that they've almost surely never seen before. I want to find a way to express this in nontechnical terms in the menu. |
|
From: Jean-Marc V. <ver...@if...> - 2000-06-23 02:34:12
|
On Jun 22, 7:02pm, Robert L Krawitz wrote: > From: Ralph Corderoy <ra...@in...> > > > > I'd call it "1440x720 with 4x vertical oversampling". A bit wordy, > > > but it's clear what it is. > > > > That's a bit verbose to fit in the menu, and that's also a name aimed > > at people who understand the technical details. I want a name that > > makes sense to people who *don't* have the technical background to > > understand this, but. > > That's a tough requirement. They probably need to learn about > resolutions. Otherwise, how about `1st Class', `2nd Class'... or > Bestest, Best, Better, Good... :-) > > They already know from their manual that the printer supports 360x360, > 720x720, and 1440x720, and that they get better as the numbers go > higher. Oversampling is a technical term that they've almost surely > never seen before. I want to find a way to express this in > nontechnical terms in the menu. > I'd call it "Software 1440x2880". Actually I'd call "1440x720 Enhanced" "Software 1440x1440" as well. I know it doesn't tell about the physical resolution but anyone sensible would think it's done at the highest possible physical resolution, which is 1440x720, isn't it ? -- -- Jean-Marc Verbavatz <ver...@if...> 5, rue La Fontaine "http://perso.cybercable.fr/verbavat" F-75016 Paris |
|
From: Robert L K. <rl...@al...> - 2000-06-23 02:47:47
|
Date: Fri, 23 Jun 2000 02:35:09 +0000 From: Jean-Marc Verbavatz <ver...@if...> I'd call it "Software 1440x2880". Actually I'd call "1440x720 Enhanced" "Software 1440x1440" as well. I know it doesn't tell about the physical resolution but anyone sensible would think it's done at the highest possible physical resolution, which is 1440x720, isn't it ? I like that better than anything else I've seen... (I still have to try your new stuff; I'm in the middle of printing out a PDI target at 1440x2880. Both rendering and printing are amazingly slow at that resolution.) -- Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Jean-Marc V. <ver...@if...> - 2000-06-23 11:44:36
|
Hi, After struggling for a couple of days with several problems, I've finally released an update last night. I've checked that it works well on epson's 800 and 850 in addition to my 870. On the 870, there's still a problem of density going up with quality. It doesn't appear to show on the 800,850. I'll see that tonight. Also I've had to reverse the ink budget quite a bit and I expect laying down too much ink in some modes/printers. I will try it myself (in addition to possible other volunteers) on an epson photo 700 today if I have time. Ordered dithering which didn't work well on multiple ink level printers should do much better now. Grain and random black spots should be largely gone. -- -- Jean-Marc Verbavatz <ver...@if...> 5, rue La Fontaine "http://perso.cybercable.fr/verbavat" F-75016 Paris |
|
From: Robert L K. <rl...@al...> - 2000-06-23 12:23:35
|
Date: Fri, 23 Jun 2000 11:45:29 +0000 From: Jean-Marc Verbavatz <ver...@if...> After struggling for a couple of days with several problems, I've finally released an update last night. I've checked that it works well on epson's 800 and 850 in addition to my 870. On the 870, there's still a problem of density going up with quality. It doesn't appear to show on the 800,850. I'll see that tonight. Also I've had to reverse the ink budget quite a bit and I expect laying down too much ink in some modes/printers. I will try it myself (in addition to possible other volunteers) on an epson photo 700 today if I have time. Ordered dithering which didn't work well on multiple ink level printers should do much better now. Grain and random black spots should be largely gone. Certainly looks very good. We're really down to the nitpicking stage now. There really aren't any pathological problems left, and it sounds like you know what most of the problems are, but just for completeness' sake: 1) Ordered dither uses a lot more ink than, say, adaptive hybrid. 2) 1440x1440 is somewhat muddy (poor saturation). The excessive ink may have something to do with it. 3) 720x720, and to a lesser extent 1440x720, using adaptive hybrid show dark dots in the lighter parts of the dark color region in colors.tif. 1440x1440 doesn't show much if any of this, and ordered dither also looks clean in this regard. 4) 720x720 shows visible transitions in ordered dithering; 1440x720 barely shows this effect, and 1440x1440 doesn't. It's most visible if you look at it from about 18" away (using a 1.5"x1.5" print of colors.tif). In any event, this effect is far less objectionable than the current mainline in that regard. 5) Black isn't perfectly uniform across different modes. I want to emphasize that I mean that it is possible to see a difference, not that the difference is great. The dark regions at 720x720 look more black than 1440x720, which in turn looks very slightly more black than 1440x1440. Again, I want to emphasize that this effect is very subtle. I have not tried to compare performance between the two codes, because the mainline has seen significant optimization. That will not be a criterion for cutting over, because optimization can always be done later. I don't have time to plug in my EX this morning to try it, but I'll try to do it tonight if no one else gets to it first. We need someone with a 740 or 760 or 900 to try this, too. We're getting really close to cutting over, so people should really start putting this to the test. |
|
From: Jean-Marc V. <ver...@if...> - 2000-06-24 08:26:00
|
I've had a quick shot at the stylus photo 700. So now only 740 an the likes are missing. It does not look too bad, but will stand to be improved. I particularly see problems linked to ink budget here too; streaks. Also midtone grays are yellowish unlike with 8x0 printers. > 1) Ordered dither uses a lot more ink than, say, adaptive hybrid. It does that on the 700 too. > > 2) 1440x1440 is somewhat muddy (poor saturation). The excessive ink > may have something to do with it. Again, ink increases with quality on the 700. > 3) 720x720, and to a lesser extent 1440x720, using adaptive hybrid > show dark dots in the lighter parts of the dark color region in > colors.tif. 1440x1440 doesn't show much if any of this, and > ordered dither also looks clean in this regard. Same thing with the 800s and the 700. Probably associated to darkness values (m_darkness in particular). > > 4) 720x720 shows visible transitions in ordered dithering; 1440x720 > barely shows this effect, and 1440x1440 doesn't. It's most visible > if you look at it from about 18" away (using a 1.5"x1.5" print of > colors.tif). In any event, this effect is far less objectionable > than the current mainline in that regard. I haven' tried the mainline recently. If you mean transitions between ink levels (in the same color) then I agree. That might be the best way to improve the ratios further. > > 5) Black isn't perfectly uniform across different modes. I want to > emphasize that I mean that it is possible to see a difference, not > that the difference is great. The dark regions at 720x720 look > more black than 1440x720, which in turn looks very slightly more > black than 1440x1440. Again, I want to emphasize that this effect > is very subtle. I've noticed that transitions between black and no black were smoother at say 720x720 than 1440x1440. All of this may again be related to excessive ink in high quality modes. > I don't have time to plug in my EX this morning to try it, but I'll > try to do it tonight if no one else gets to it first. We need someone > with a 740 or 760 or 900 to try this, too. We're getting really close > to cutting over, so people should really start putting this to the > test. The change in ink density between qualities is the next thing I will address because it is both most visible and could play a significant role in many other defects. Can you give me a brief explanation of the difference between horizontal_passes and real_horizontal_passes for one thing and also of vertical_passes vs vertical_subsample ? I'm not sure I understand that right. -- -- Jean-Marc Verbavatz <ver...@if...> 5, rue La Fontaine "http://perso.cybercable.fr/verbavat" F-75016 Paris |
|
From: Robert L K. <rl...@al...> - 2000-06-24 12:51:24
|
Date: Fri, 23 Jun 2000 22:53:28 +0000 Cc: gim...@so... From: Jean-Marc Verbavatz <ver...@if...> The change in ink density between qualities is the next thing I will address because it is both most visible and could play a significant role in many other defects. Can you give me a brief explanation of the difference between horizontal_passes and real_horizontal_passes for one thing and also of vertical_passes vs vertical_subsample ? I'm not sure I understand that right. horizontal_passes is the number of passes required to achieve the desired horizontal resolution. real_horizontal_passes is the number of passes required to achieve the desired resolution assuming that the printer can print 720 dpi horizontally. Studying the code just now, I notice that real_horizontal_passes isn't actually used anywhere, so I've just taken it out of my sandbox. So the real answer is the first one. For example, an 870 prints at 360 dpi when using variable dot size. In order to achieve 1440 dpi, four horizontal passes must be used. vertical_passes is the number of times each point is covered, without any oversampling. This is a technique used to reduce banding without increasing resolution or (to a significant extent) rendering time. For example, 720x720 dpi can be printed with either 1, 2, or 4 vertical_passes. 720 dpi softweave is 1, 720 dpi high quality is 2, and 720 dpi highest quality is 4. Each pixel that is turned on is assigned to one of the vertical_passes in round robin order, so each pass prints the same amount of ink. Each vertical_pass is printed with a different jet, except near the top and bottom of the page. vertical_subsample is misnamed; it should be named vertical_oversample. In fact, I'm doing that in my sandbox right now, also. That's simply the excess vertical resolution over the printer's actual capability. -- Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Jean-Marc V. <ver...@if...> - 2000-07-08 15:09:32
|
I'm back and just went throught the mail archive, but I haven't yet had time to look at the repository. > I found my problem -- saturation adjustment must be done in terms of > HSL (hue-saturation-lightness) rather than HSV space. Yes indeed. > > This also suggests that perhaps our brightness computation is being > done incorrectly, and that perhaps we should be doing that in HSL > space rather than on a per-channel basis (like gamma is). Thoughts? > I don't think so. I haven't actually looked at what was done, but brightness contrast and gamma should be on a per-channel basis. In HLS, you _might_ want to add adjustable lightness and hue, but this won't help with brightness. -- -- Jean-Marc Verbavatz <ver...@if...> 5, rue La Fontaine "http://perso.cybercable.fr/verbavat" F-75016 Paris |
|
From: Jean-Marc V. <ver...@if...> - 2000-07-08 15:16:47
|
On Jun 30, 1:54pm, Robert L Krawitz wrote: > Subject: Re: [Gimp-print-devel] Jmv-branch > Date: Fri, 30 Jun 2000 18:24:43 +0200 > From: Thomas Tonino <tt...@bi...> > CC: ver...@if..., gim...@so... > > Robert L Krawitz wrote: > > > > Date: Thu, 29 Jun 2000 00:56:14 +0000 > > From: Jean-Marc Verbavatz <ver...@if...> > > > > - At highest qualities, ordered dithering still lays down too much > > ink. There's not much I can do about it. In the absence of error > > propagation, it's rather difficult to print exactly what's needed. > > > > Why? If you reduce the density appropriately, the same amount of ink > > should be laid down. > > My bet is that JMV is more efficient with ink. With ordered dither, the > inks are laid down independently. Compare: > > That makes sense. I'm more interested in getting Jean-Marc's good > stuff than in preserving the quality of ordered dither per se. If > worst comes to worst, we can have two different dither routines, one > using Jean-Marc's stuff and the other using the current mainline or > the like, so that someone who wants a fast ordered dither can do > that. > > I guess ordered dither is outclassed now at high densities. For lowest > densities it still rules, at least when compared to the main branch. I > guess I'll have to reserve some time again to do testing. > > That's fine, that's what the adaptive stuff is all about. I came, more or less, to the same conclusions concerning ordered dithering. However, it may remain useful for some printer/quality combinations. In fact, I think it may not be difficult to predict (and perhaps to make it the default setting) which dithering will give best result from: printer, quality and image type settings. -- -- Jean-Marc Verbavatz <ver...@if...> 5, rue La Fontaine "http://perso.cybercable.fr/verbavat" F-75016 Paris |
|
From: Ralph C. <ra...@in...> - 2000-07-23 11:56:21
|
Hi, > > The file is ~5.9Mb, and is attached. > > Whoa! Watch out about mailing files like that to the entire list. Indeed. Any way of configuring SourceForge's MailMan to set a maximum message size. This won't be the large multi-megabyte mail message and some of us Europeans have to pay for our phone time online :-( Ralph. |
|
From: Robert L K. <rl...@al...> - 2000-07-23 12:45:43
|
Date: Sun, 23 Jul 2000 12:56:17 +0100 From: Ralph Corderoy <ra...@in...> > > The file is ~5.9Mb, and is attached. > > Whoa! Watch out about mailing files like that to the entire list. Indeed. Any way of configuring SourceForge's MailMan to set a maximum message size. This won't be the large multi-megabyte mail message and some of us Europeans have to pay for our phone time online :-( I took a look around, and I found such an option. I set it to 64K. -- Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Ralph C. <ra...@in...> - 2000-07-31 09:18:03
|
Hi,
> I'm with Thomas in that we want a short, catchy name. Both
> gimp-print and stp are good in that regard, although gimp-print is
> obviously too catchy in ways that are becoming less desirable.
IMHO `stp' isn't catchy :-(
How about a word that is catchy and is associated with printing, like
`Calico'.
2. Cotton cloth printed with a figured pattern.
Note: In the United States the term calico is applied only to
the printed fabric.
Ralph.
|
|
From: Michael S. <mi...@ea...> - 2000-07-31 13:45:33
|
Ralph Corderoy wrote: > ... > How about a word that is catchy and is associated with printing, > like `Calico'. > ... I like it! -- ______________________________________________________________________ Michael Sweet, Easy Software Products mi...@ea... Printing Software for UNIX http://www.easysw.com |
|
From: Robert L K. <rl...@al...> - 2000-08-03 02:04:04
|
Date: Mon, 31 Jul 2000 10:17:58 +0100 From: Ralph Corderoy <ra...@in...> How about a word that is catchy and is associated with printing, like `Calico'. 2. Cotton cloth printed with a figured pattern. Note: In the United States the term calico is applied only to the printed fabric. Well, nothing shows up on Freshmeat as being named "calico". There is a calico.com that seems to be an e-business outfit. I don't know if that's an issue or not. -- Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Ralph C. <ra...@in...> - 2000-08-07 08:51:22
|
Hi, > BTW, I have no objection to the name Calico, although I don't really > think of calico as a "print"; it's more of a pattern. It probably > would be nice to rename it before the release. Calico was just my second suggestion, I see calico.org has already been taken. If it doesn't suggest printing to you then how about `litho' from lithography? Lithography \Li*thog"ra*phy\, n. [Cf. F. lithographie.] The art or process of putting designs or writing, with a greasy material, on stone, and of producing printed impressions therefrom. The process depends, in the main, upon the antipathy between grease and water, which prevents a printing ink containing oil from adhering to wetted parts of the stone not covered by the design. See {Lithographic limestone}, under {Lithographic}. Ralph. |
|
From: Ralph C. <ra...@in...> - 2000-09-22 20:20:58
|
Hi,
> > > Mike, there are other good reasons to use mkdir -p besides the
> > > obnoxious warnings.
> >
> > Unfortunately, the "-p" option is not portable. It's implemented
> > in most of the newer versions of the commercial UNIX's, but not
> > all, and certainly not by the older versions.
>
> As I recall, AIX 4.1 doesn't implement it.
Strange, I know AIX 3.2.5 does.
> The problem, of course, is what happens if the parent directory
> doesn't already exist. The warnings are very annoying, particularly
> in silent mode (when the makefile is printing out everything it's
> doing, it's a bit easier to see what's going on.
>
> Another option is to implement a local mkdir_p command.
I think it is very common to have a `mkdir -p' replacement shell script
bundled with autoconf'd source. I don't know if there's a `standard'
one that comes as part of autoconf. cdrecord-1.9 contains
conf/mkdir-sh which is GPL'd. I don't know if it's any good :-)
Ralph.
#!/bin/sh
#
# Replacement for mkdir -p ... functionality.
#
# BSD-4.3, NeXT Step <= 3.x and similar don't accept the -p flag
#
# @(#)mkdir-sh 1.2 98/12/14 Copyright 1998 J. Schilling
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; see the file COPYING. If not, write to
# the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
if [ $# -lt 1 ]; then
echo "Usage: mkdir-sh [-p] dir ...."
exit 1
fi
dop=false
case $1 in
-p)
dop=true
shift
;;
esac
if [ $dop = false ]; then
for i in "$@"; do
mkdir "$i"
done
else
for i in "$@"; do
if [ -d "$i" ]; then
continue
fi
# Don't use ${i:-.}, BSD4.3 doen't like it
#
fullname="$i"
if [ ."$i" = . ]; then
fullname=.
fi
dirname=`expr \
"$fullname/" : '\(/\)/*[^/]*//*$' \| \
"$fullname/" : '\(.*[^/]\)//*[^/][^/]*//*$' \| \
.`
sh $0 -p "$dirname"
mkdir "$i"
done
fi
|
|
From: Robert L K. <rl...@al...> - 2000-09-23 00:01:45
|
Date: Fri, 22 Sep 2000 21:20:35 +0100 From: Ralph Corderoy <ra...@in...> > > Unfortunately, the "-p" option is not portable. It's implemented > > in most of the newer versions of the commercial UNIX's, but not > > all, and certainly not by the older versions. > > As I recall, AIX 4.1 doesn't implement it. Strange, I know AIX 3.2.5 does. I thought it was AIX 4.1. I could be wrong. It might be NCR MP-RAS. I know I've stumbled across something that doesn't. > The problem, of course, is what happens if the parent directory > doesn't already exist. The warnings are very annoying, particularly > in silent mode (when the makefile is printing out everything it's > doing, it's a bit easier to see what's going on. > > Another option is to implement a local mkdir_p command. I think it is very common to have a `mkdir -p' replacement shell script bundled with autoconf'd source. I don't know if there's a `standard' one that comes as part of autoconf. cdrecord-1.9 contains conf/mkdir-sh which is GPL'd. I don't know if it's any good :-) That looks like a useful script. Thanks. -- Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Ralph C. <ra...@in...> - 2000-12-08 11:29:45
|
Hi Robert, > I'm also going to add some additional resolutions to the Epson > driver, which will be named "fast", for printing bidirectionally. So > if there's a "720 DPI High Quality Fast", it will print > bidirectionally; "720 DPI High Quality" will print unidirectionally. Just a suggestion from the user's POV. If it isn't clear from the user interface that Fast <=> Bi-directional then how about calling it bi-directional to avoid confusion over what all the different `resolutions' actually mean. Users will understand that it means it prints in both directions and is therefore faster also possibly with less accuracy. Otherwise, we could end up with Fast, Faster, and Fastish all meaning different things behind the scenes. Ralph. |
|
From: Robert L K. <rl...@al...> - 2000-12-09 00:33:46
|
Date: Fri, 08 Dec 2000 11:29:35 +0000 From: Ralph Corderoy <ra...@in...> > I'm also going to add some additional resolutions to the Epson > driver, which will be named "fast", for printing bidirectionally. So > if there's a "720 DPI High Quality Fast", it will print > bidirectionally; "720 DPI High Quality" will print unidirectionally. Just a suggestion from the user's POV. If it isn't clear from the user interface that Fast <=> Bi-directional then how about calling it bi-directional to avoid confusion over what all the different `resolutions' actually mean. That's a good suggestion. The only problem is that some of the resolution names will get very long. I suppose if it all goes through foomatic it doesn't really matter that much. -- Robert Krawitz <rl...@al...> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail lp...@uu... Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Thomas T. <tt...@bi...> - 2000-12-09 08:08:29
|
Robert L Krawitz wrote: > Just a suggestion from the user's POV. If it isn't clear from the user > interface that Fast <=> Bi-directional then how about calling it > bi-directional to avoid confusion over what all the different > `resolutions' actually mean. > > That's a good suggestion. The only problem is that some of the > resolution names will get very long. I suppose if it all goes through > foomatic it doesn't really matter that much. bi-dir instead of bi-directional may be nearly as clear, and is short. Thomas |
|
From: Ralph C. <ra...@in...> - 2001-02-03 15:16:55
|
Hi, > Actually, there are apparently at least four command sets for > different purposes: escp2 for actual printing (which is well > documented), remote mode (which controls miscellaneous printer > features, which has been somewhat more grudgingly documented), packet > mode (which I have no real idea what it does; there's one command > that's needed to even allow newer printers to print; that particular > command is documented), and something else (which includes the ink > cartridge command). So it's rather complex, so say the least. Wonder if any of that overrides an ink cartridge saying `I'm empty' so it is used for printing. Conspiracy-theory-of-the-day-ly yrs, Ralph. |
|
From: Robert L K. <rl...@al...> - 2001-02-03 15:26:16
|
Date: Sat, 03 Feb 2001 15:16:57 +0000 From: Ralph Corderoy <ra...@in...> > Actually, there are apparently at least four command sets for > different purposes: escp2 for actual printing (which is well > documented), remote mode (which controls miscellaneous printer > features, which has been somewhat more grudgingly documented), packet > mode (which I have no real idea what it does; there's one command > that's needed to even allow newer printers to print; that particular > command is documented), and something else (which includes the ink > cartridge command). So it's rather complex, so say the least. Wonder if any of that overrides an ink cartridge saying `I'm empty' so it is used for printing. Conspiracy-theory-of-the-day-ly yrs, Well, the 480 and 580 don't use a chipped cartridge. It's possible that there's some hidden command for testing that feature, but I'm inclined to suspect that the actual ink levels are stored entirely on the cartridge (although they're actually set by the printer). |
|
From: Ralph C. <ra...@in...> - 2001-02-17 10:48:51
|
Hi,
> > Also, remember that HP-UX uses .sl for shared libraries... :(
>
> AIX does (or at least did) something even stranger.
AIX 3.2.5's shared libraries look like normal archives, *.a.
$ ar tv /lib/libX11.a
rwxr-xr-x 300/200 2263 Oct 23 02:47 1992 shr4net.o
rwxr-x--- 300/300 885514 Jun 16 19:05 1997 shr4.o
rw-r--r-- 300/200 398857 Oct 23 02:47 1992 shr.o
Ralph.
|
|
From: Roger L. <rl...@yo...> - 2001-02-17 22:37:57
|
On Sat, Feb 17, 2001 at 10:48:54AM +0000, Ralph Corderoy wrote: > AIX 3.2.5's shared libraries look like normal archives, *.a. > > $ ar tv /lib/libX11.a > rwxr-xr-x 300/200 2263 Oct 23 02:47 1992 shr4net.o > rwxr-x--- 300/300 885514 Jun 16 19:05 1997 shr4.o > rw-r--r-- 300/200 398857 Oct 23 02:47 1992 shr.o Out of interest, how are these used. You can't just mmap() it in, can you? Or is black magic involved to link? -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ For GPG Public Key: finger rl...@to... or see public keyservers. |
|
From: Ralph C. <ra...@in...> - 2001-02-18 12:36:36
|
Hi, > In 4.1, we've done a major reorganization of our code base, creating > a new shared library (libgimpprint.so) that applications (such as the > print plugin, Ghostscript, and CUPS drivers) can link against. The > intent is that libgimpprint (which is not dependent on anything else, > such as the Gimp, GTK, etc.) be installed as part of the underlying > infrastructure that the print plugin can depend upon. It's called libgimpprint.so but it doesn't depend on the Gimp. Isn't now the time to take the plunge and rename gimp-print? The longer it continues under its current misleading name the more pain there will be in changing it. The conversation about a new name has been had before. The best I could suggest was `calico' for which the .org was available. It must be confusing for new users that they don't have to print from the Gimp and could be slowing take-up of gimp-print. Ralph. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X