Menu
▾
▴
lpr-discuss
|
From: Mark F. <mf...@va...> - 2000-11-25 21:56:27
|
libprintsys (0.3) has been added to the gnulpr repository, under bens_dev_branch. --Mark -- If we were meant to get up early, God would have created us with alarm clocks. Mark James Fasheh <mf...@va...> VA Linux Systems Professional Services http://www.exothermic.org |
|
From: Ben W. <be...@va...> - 2000-11-26 00:27:08
|
Where is Mark P's printcap writing routines? Why don't we rename the functions and structrures so that they are now "gnulpr" but rather "lps"? Also, how does this sound to people? Right now we don't have anything that uses libprintsys in gnulpr. Why don't we stave off converting everything until the 1.1 release? Then in the 1.1 release we will: 1) introduce gpanda 2) introduce libprintsys 3) introduce gprintool 4) convert gpr to using libprintsys 5) convert the spooler to using libprintsys -ben > libprintsys (0.3) has been added to the gnulpr repository, under > bens_dev_branch. > --Mark > > -- > If we were meant to get up early, God would have created us with alarm clocks. > Mark James Fasheh <mf...@va...> > VA Linux Systems Professional Services > http://www.exothermic.org > _______________________________________________ > Lpr-discuss mailing list > Lpr...@li... > http://lists.sourceforge.net/mailman/listinfo/lpr-discuss |
|
From: Mark F. <mf...@va...> - 2000-11-26 01:30:33
|
On Sat, Nov 25, 2000 at 04:15:14PM -0800, Ben Woodard wrote: > Where is Mark P's printcap writing routines? If they're not in the .3 tarball, they'll have to be added. At least this way, we have a base version in a centralized location which can be patched up to include all the features developed recently. > > Why don't we rename the functions and structrures so that they are now > "gnulpr" but rather "lps"? > > Also, how does this sound to people? Right now we don't have anything > that uses libprintsys in gnulpr. Why don't we stave off converting > everything until the 1.1 release? Then in the 1.1 release we will: > > 1) introduce gpanda > 2) introduce libprintsys > 3) introduce gprintool > 4) convert gpr to using libprintsys > 5) convert the spooler to using libprintsys If you indeed want to make a 1.0 release by the end of this month, it seems that this might make the most sense. That way you can concentrate on the release, rather than rushing everything in these last couple of days. > > -ben > > > libprintsys (0.3) has been added to the gnulpr repository, under > > bens_dev_branch. > > --Mark > > > > -- > > If we were meant to get up early, God would have created us with alarm clocks. > > Mark James Fasheh <mf...@va...> > > VA Linux Systems Professional Services > > http://www.exothermic.org > > _______________________________________________ > > Lpr-discuss mailing list > > Lpr...@li... > > http://lists.sourceforge.net/mailman/listinfo/lpr-discuss > > _______________________________________________ > Lpr-discuss mailing list > Lpr...@li... > http://lists.sourceforge.net/mailman/listinfo/lpr-discuss -- If we were meant to get up early, God would have created us with alarm clocks. Mark James Fasheh <mf...@va...> VA Linux Systems Professional Services http://www.exothermic.org |
|
From: Mark P. <mp...@va...> - 2000-11-27 14:50:55
|
Ben Woodard wrote:
>
> Where is Mark P's printcap writing routines?
They're (it's) in there. Look in printcap.c:
/*-------------------------------------------------------------------
Using the data from printerlist, write a printcap file to filename.
-------------------------------------------------------------------*/
int printcap_write (char *filename, char **printerlist) {
Also, there are some changes to the data structures
that hold the parsed printcap info:
/***** Pair data structure and functions *****/
typedef struct{
char *key;
char *value;
int type; <-- NEW
} GLPR_PairType;
char *glpr_pair_lookup(GLPR_PairType *pairs, const char *key);
/***** Printer data structures and functions *****/
typedef struct{
char **names;
GLPR_PairType *fields;
char *comments; <-- NEW
GLPR_PairType tc_field; <-- NEW
GLPR_PairType *tc_position; <-- NEW
} GLPR_PrinterType;
The type field in GLPR_PairType was necessary to correctly
determine the output format for a value. It's one of
these values:
enum {
PCAP_STRING,
PCAP_NUMERIC,
PCAP_BOOLEAN
};
It can be safely ignored if all you're doing is reading,
but it ensures that the printcap, when written, is
equivalent to the printcap that was read.
The comments field of GLPR_PrinterType is similarly
there to avoid loosing comments when a printcap is written.
All entire-line comment blocks that precede a printcap entry
are assumed to "belong" to that entry, and are written
out when the printcap is output with printcap_write().
The tc_field and tc_position fields are used to maintain
information about a tc field within the printcap entry.
The printcap reading routines resolved nested tc information
but the original tc reference was lost - not good when
you want to write them out again - so I save the info, as
well as a pointer to its location within the pair list.
>
> Why don't we rename the functions and structrures so that they are now
> "gnulpr" but rather "lps"?
I plan to do this in my next revision.
> Also, how does this sound to people? Right now we don't have anything
> that uses libprintsys in gnulpr. Why don't we stave off converting
> everything until the 1.1 release? Then in the 1.1 release we will:
>
> 1) introduce gpanda
> 2) introduce libprintsys
> 3) introduce gprintool
> 4) convert gpr to using libprintsys
> 5) convert the spooler to using libprintsys
>
> -ben
>
> > libprintsys (0.3) has been added to the gnulpr repository, under
> > bens_dev_branch.
> > --Mark
> >
> > --
> > If we were meant to get up early, God would have created us with alarm clocks.
> > Mark James Fasheh <mf...@va...>
> > VA Linux Systems Professional Services
> > http://www.exothermic.org
> > _______________________________________________
> > Lpr-discuss mailing list
> > Lpr...@li...
> > http://lists.sourceforge.net/mailman/listinfo/lpr-discuss
--
------------------------------------------------------
Mark Pruett VA Linux Systems
mp...@va... Open Source Printing
------------------------------------------------------
|
|
From: Ben W. <be...@va...> - 2000-11-28 03:09:35
|
Ah OK. I see it now. Then there is something else you need to do. You
need to propegate the changes up to the next level and put them in the
printsys.h header file. Remember the printcap routines are just the
backend routines that do the work for the exported interface which is
the stuff in printsys.h
-ben
> Ben Woodard wrote:
> >
> > Where is Mark P's printcap writing routines?
>
> They're (it's) in there. Look in printcap.c:
>
> /*-------------------------------------------------------------------
> Using the data from printerlist, write a printcap file to filename.
> -------------------------------------------------------------------*/
> int printcap_write (char *filename, char **printerlist) {
>
> Also, there are some changes to the data structures
> that hold the parsed printcap info:
>
> /***** Pair data structure and functions *****/
> typedef struct{
> char *key;
> char *value;
> int type; <-- NEW
> } GLPR_PairType;
>
> char *glpr_pair_lookup(GLPR_PairType *pairs, const char *key);
>
> /***** Printer data structures and functions *****/
> typedef struct{
> char **names;
> GLPR_PairType *fields;
> char *comments; <-- NEW
> GLPR_PairType tc_field; <-- NEW
> GLPR_PairType *tc_position; <-- NEW
> } GLPR_PrinterType;
>
> The type field in GLPR_PairType was necessary to correctly
> determine the output format for a value. It's one of
> these values:
>
> enum {
> PCAP_STRING,
> PCAP_NUMERIC,
> PCAP_BOOLEAN
> };
>
> It can be safely ignored if all you're doing is reading,
> but it ensures that the printcap, when written, is
> equivalent to the printcap that was read.
>
> The comments field of GLPR_PrinterType is similarly
> there to avoid loosing comments when a printcap is written.
> All entire-line comment blocks that precede a printcap entry
> are assumed to "belong" to that entry, and are written
> out when the printcap is output with printcap_write().
>
> The tc_field and tc_position fields are used to maintain
> information about a tc field within the printcap entry.
> The printcap reading routines resolved nested tc information
> but the original tc reference was lost - not good when
> you want to write them out again - so I save the info, as
> well as a pointer to its location within the pair list.
>
> >
> > Why don't we rename the functions and structrures so that they are now
> > "gnulpr" but rather "lps"?
>
> I plan to do this in my next revision.
>
> > Also, how does this sound to people? Right now we don't have anything
> > that uses libprintsys in gnulpr. Why don't we stave off converting
> > everything until the 1.1 release? Then in the 1.1 release we will:
> >
> > 1) introduce gpanda
> > 2) introduce libprintsys
> > 3) introduce gprintool
> > 4) convert gpr to using libprintsys
> > 5) convert the spooler to using libprintsys
> >
> > -ben
> >
> > > libprintsys (0.3) has been added to the gnulpr repository, under
> > > bens_dev_branch.
> > > --Mark
> > >
> > > --
> > > If we were meant to get up early, God would have created us with alarm clocks.
> > > Mark James Fasheh <mf...@va...>
> > > VA Linux Systems Professional Services
> > > http://www.exothermic.org
> > > _______________________________________________
> > > Lpr-discuss mailing list
> > > Lpr...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/lpr-discuss
>
> --
> ------------------------------------------------------
> Mark Pruett VA Linux Systems
> mp...@va... Open Source Printing
> ------------------------------------------------------
|
Thanks for helping keep SourceForge clean.
X