Menu
▾
▴
omniprint-developer — Discussion of the Omni driver by developers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(24) |
Nov
(8) |
Dec
(16) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(21) |
Feb
(3) |
Mar
|
Apr
(3) |
May
(3) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(4) |
Nov
(2) |
Dec
|
| 2003 |
Jan
|
Feb
(2) |
Mar
(9) |
Apr
(9) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2004 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(6) |
Oct
(6) |
Nov
(2) |
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(6) |
| 2007 |
Jan
(6) |
Feb
(6) |
Mar
|
Apr
(2) |
May
(2) |
Jun
(6) |
Jul
(8) |
Aug
(2) |
Sep
(2) |
Oct
(1) |
Nov
(1) |
Dec
(4) |
| 2008 |
Jan
(5) |
Feb
(5) |
Mar
(26) |
Apr
(17) |
May
(17) |
Jun
(6) |
Jul
(26) |
Aug
(7) |
Sep
(16) |
Oct
(15) |
Nov
(30) |
Dec
(30) |
| 2009 |
Jan
(8) |
Feb
(16) |
Mar
(11) |
Apr
(17) |
May
(35) |
Jun
(24) |
Jul
(28) |
Aug
(5) |
Sep
(3) |
Oct
|
Nov
|
Dec
(13) |
| 2010 |
Jan
(8) |
Feb
(3) |
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(2) |
Sep
(3) |
Oct
(2) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Mark H. <ha...@us...> - 2002-02-13 22:26:26
|
Hey Tim, I was wondering if you or anyone else can help. I cannot compile the new directory JobDialog with gcc 3.0. It is in the latest CVS. Here is the build log. It works on 2.96. I have installed the following packages: -rw-rw-r-- 1 hamzy hamzy 1154814 Feb 11 15:51 gtkmm-1.2.5-1.i386.rpm -rw-rw-r-- 1 hamzy hamzy 683654 Feb 11 15:51 gtkmm-devel-1.2.5-1.i386.rpm -rw-rw-r-- 1 hamzy hamzy 64954 Feb 11 15:51 libsigc++-1.0.1-0_helix_1.i386.rpm -rw-rw-r-- 1 hamzy hamzy 65868 Feb 11 15:51 libsigc++-devel-1.0.1-0_helix_1.i386.rpm cpp0: warning: changing search order for system directory "/usr/include" cpp0: warning: as it has already been specified as a non-system directory cpp0: warning: changing search order for system directory "/usr/include" cpp0: warning: as it has already been specified as a non-system directory cpp0: warning: changing search order for system directory "/usr/include" cpp0: warning: as it has already been specified as a non-system directory cpp0: warning: changing search order for system directory "/usr/include" cpp0: warning: as it has already been specified as a non-system directory cpp0: warning: changing search order for system directory "/usr/include" cpp0: warning: as it has already been specified as a non-system directory cpp0: warning: changing search order for system directory "/usr/include" cpp0: warning: as it has already been specified as a non-system directory cpp0: warning: changing search order for system directory "/usr/include" cpp0: warning: as it has already been specified as a non-system directory cpp0: warning: changing search order for system directory "/usr/include" cpp0: warning: as it has already been specified as a non-system directory cpp0: warning: changing search order for system directory "/usr/include" cpp0: warning: as it has already been specified as a non-system directory cpp0: warning: changing search order for system directory "/usr/include" cpp0: warning: as it has already been specified as a non-system directory c++ -march=i386 -mcpu=i686 -Wall -DGCC_VER_3 -DRETAIL=1 -I .. -I/usr/lib/gtkmm/include -I/usr/include -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/lib/sigc++/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -c ComboBoxHandler.cpp cc1plus: warning: changing search order for system directory "/usr/include" cc1plus: warning: as it has already been specified as a non-system directory c++ -march=i386 -mcpu=i686 -Wall -DGCC_VER_3 -DRETAIL=1 -I .. -I/usr/lib/gtkmm/include -I/usr/include -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/lib/sigc++/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -c Driver.cpp cc1plus: warning: changing search order for system directory "/usr/include" cc1plus: warning: as it has already been specified as a non-system directory c++ -march=i386 -mcpu=i686 -Wall -DGCC_VER_3 -DRETAIL=1 -I .. -I/usr/lib/gtkmm/include -I/usr/include -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/lib/sigc++/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -c DriverInfo.cpp cc1plus: warning: changing search order for system directory "/usr/include" cc1plus: warning: as it has already been specified as a non-system directory c++ -march=i386 -mcpu=i686 -Wall -DGCC_VER_3 -DRETAIL=1 -I .. -I/usr/lib/gtkmm/include -I/usr/include -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/lib/sigc++/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -c DriverProperty.cpp cc1plus: warning: changing search order for system directory "/usr/include" cc1plus: warning: as it has already been specified as a non-system directory c++ -march=i386 -mcpu=i686 -Wall -DGCC_VER_3 -DRETAIL=1 -I .. -I/usr/lib/gtkmm/include -I/usr/include -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/lib/sigc++/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -c JobPropertyDialogController.cpp cc1plus: warning: changing search order for system directory "/usr/include" cc1plus: warning: as it has already been specified as a non-system directory c++ -march=i386 -mcpu=i686 -Wall -DGCC_VER_3 -DRETAIL=1 -I .. -I/usr/lib/gtkmm/include -I/usr/include -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/lib/sigc++/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -c JobPropertyDialogView.cpp cc1plus: warning: changing search order for system directory "/usr/include" cc1plus: warning: as it has already been specified as a non-system directory c++ -march=i386 -mcpu=i686 -Wall -DGCC_VER_3 -DRETAIL=1 -I .. -I/usr/lib/gtkmm/include -I/usr/include -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/lib/sigc++/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -c TextBoxHandler.cpp cc1plus: warning: changing search order for system directory "/usr/include" cc1plus: warning: as it has already been specified as a non-system directory c++ -march=i386 -mcpu=i686 -Wall -DGCC_VER_3 -DRETAIL=1 -I .. -I/usr/lib/gtkmm/include -I/usr/include -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/lib/sigc++/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -c WidgetManager.cpp cc1plus: warning: changing search order for system directory "/usr/include" cc1plus: warning: as it has already been specified as a non-system directory c++ -march=i386 -mcpu=i686 -Wall -DGCC_VER_3 -DRETAIL=1 -I .. -I/usr/lib/gtkmm/include -I/usr/include -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/lib/sigc++/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -c OmniGSInterface.c cc1plus: warning: changing search order for system directory "/usr/include" cc1plus: warning: as it has already been specified as a non-system directory c++ -shared -Wl,-soname,libomnijobdialog.so -o libomnijobdialog.so -L .. -lomni -rdynamic -L/usr/lib -L/usr/X11R6/lib -lgtkmm -lgdkmm -lgtk -lgdk -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm -lsigc -lpthread -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm ComboBoxHandler.o Driver.o DriverInfo.o DriverProperty.o JobPropertyDialogController.o JobPropertyDialogView.o TextBoxHandler.o WidgetManager.o OmniGSInterface.o c++ -march=i386 -mcpu=i686 -Wall -DGCC_VER_3 -DRETAIL=1 -I .. -I/usr/lib/gtkmm/include -I/usr/include -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/lib/sigc++/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -c Tester.cpp cc1plus: warning: changing search order for system directory "/usr/include" cc1plus: warning: as it has already been specified as a non-system directory c++ -o Tester Tester.o -L .. -lomni -rdynamic -L/usr/lib -L/usr/X11R6/lib -lgtkmm -lgdkmm -lgtk -lgdk -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm -lsigc -lpthread -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm -L . -lomnijobdialog ./libomnijobdialog.so: undefined reference to `SigC::ObjectScoped::ObjectScoped()' /usr/lib/libgtkmm.so: undefined reference to `cerr' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::proximity_in_event_impl(_GdkEventProximity*)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::delete_event_impl(_GdkEventAny*)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::draw_focus_impl()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::event_impl(_GdkEvent*)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::client_event_impl(_GdkEventClient*)' ./libomnijobdialog.so: undefined reference to `Gtk::Window::~Window()' ./libomnijobdialog.so: undefined reference to `Gtk::Main::~Main()' ./libomnijobdialog.so: undefined reference to `Gtk::Container::focus_impl(GtkDirectionType)' ./libomnijobdialog.so: undefined reference to `SigC::ScopeNode::~ScopeNode()' ./libomnijobdialog.so: undefined reference to `virtual thunk to Gtk::Window::~Window()' ./libomnijobdialog.so: undefined reference to `vtable for SigC::ScopeNode' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::realize_impl()' ./libomnijobdialog.so: undefined reference to `Gtk::Table::set_col_spacings(int)' ./libomnijobdialog.so: undefined reference to `Gtk::Main::instance_' ./libomnijobdialog.so: undefined reference to `Gtk::Container::~Container()' ./libomnijobdialog.so: undefined reference to `Gtk::Label::Label(Gtk::nstring const&, float, float)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::proximity_out_event_impl(_GdkEventProximity*)' ./libomnijobdialog.so: undefined reference to `Gtk::Main::quit' ./libomnijobdialog.so: undefined reference to `Gtk::Table::set_row_spacings(int)' ./libomnijobdialog.so: undefined reference to `SigC::ObjectScoped::~ObjectScoped()' /usr/lib/libgtkmm.so: undefined reference to `endl(ostream &)' ./libomnijobdialog.so: undefined reference to `Gtk::Window::set_modal(bool)' ./libomnijobdialog.so: undefined reference to `Gtk::Object::~Object()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::expose_event_impl(_GdkEventExpose*)' ./libomnijobdialog.so: undefined reference to `Gtk::Container::child_type_impl()' ./libomnijobdialog.so: undefined reference to `Gtk::Combo::get_entry() const' ./libomnijobdialog.so: undefined reference to `virtual thunk to Gtk::Object::set_dynamic()' ./libomnijobdialog.so: undefined reference to `Gtk::Object::unreference()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::button_release_event_impl(_GdkEventButton*)' ./libomnijobdialog.so: undefined reference to `Gtk::Combo::set_popdown_strings(Gtk::SArray_Helpers::SArray const&)' ./libomnijobdialog.so: undefined reference to `SigC::Scopes::Extend::~Extend()' ./libomnijobdialog.so: undefined reference to `virtual thunk to SigC::Object::~Object()' ./libomnijobdialog.so: undefined reference to `Gtk::Frame::Frame()' ./libomnijobdialog.so: undefined reference to `virtual thunk to Gtk::Object::unreference()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::set_usize(int, int)' ./libomnijobdialog.so: undefined reference to `Gtk::Button::Button(std::string const&, float, float)' ./libomnijobdialog.so: undefined reference to `Gtk::Container::~Container()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::draw_impl(_GdkRectangle*)' ./libomnijobdialog.so: undefined reference to `Gtk::ButtonBox::set_layout(GtkButtonBoxStyle)' ./libomnijobdialog.so: undefined reference to `Gtk::Container::add_impl(Gtk::Widget&)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::show_impl()' ./libomnijobdialog.so: undefined reference to `Gtk::Box::pack_start(Gtk::Widget&, bool, bool, unsigned)' ./libomnijobdialog.so: undefined reference to `vtable for SigC::SlotDependent' ./libomnijobdialog.so: undefined reference to `SigC::Object::~Object()' ./libomnijobdialog.so: undefined reference to `virtual thunk to Gtk::Bin::~Bin()' ./libomnijobdialog.so: undefined reference to `virtual thunk to Gtk::Object::reference()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::drag_data_received_impl(_GdkDragContext*, int, int, _GtkSelectionData*, unsigned, unsigned)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::leave_notify_event_impl(_GdkEventCrossing*)' ./libomnijobdialog.so: undefined reference to `virtual thunk to Gtk::Widget::~Widget()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::hide_all()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::size_request_impl(_GtkRequisition*)' ./libomnijobdialog.so: undefined reference to `Gtk::Combo::Combo()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::style_changed_impl(Gtk::Style*)' ./libomnijobdialog.so: undefined reference to `virtual thunk to Gtk::Object::~Object()' ./libomnijobdialog.so: undefined reference to `Gtk::Base::~Base()' ./libomnijobdialog.so: undefined reference to `vtable for SigC::SlotDependent::Dep' ./libomnijobdialog.so: undefined reference to `Gtk::ScrolledWindow::ScrolledWindow()' /usr/lib/libgtkmm.so: undefined reference to `ostream::operator<<(char const *)' ./libomnijobdialog.so: undefined reference to `Gtk::HButtonBox::HButtonBox(GtkButtonBoxStyle, int)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::set_sensitive(bool)' ./libomnijobdialog.so: undefined reference to `Gtk::ProxyNode::connect(Gtk::Object*, char const*, void (*)(), SigC::SlotData*, bool)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::show_all()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::drag_data_get_impl(_GdkDragContext*, _GtkSelectionData*, unsigned, unsigned)' ./libomnijobdialog.so: undefined reference to `Gtk::VBox::VBox(bool, int)' ./libomnijobdialog.so: undefined reference to `Gtk::Container::remove_impl(Gtk::Widget&)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::configure_event_impl(_GdkEventConfigure*)' ./libomnijobdialog.so: undefined reference to `virtual thunk to Gtk::Container::~Container()' ./libomnijobdialog.so: undefined reference to `vtable for SigC::Scopes::Extend' ./libomnijobdialog.so: undefined reference to `Gtk::Main::Main(int*, char***, bool)' ./libomnijobdialog.so: undefined reference to `Gtk::Window::Window(GtkWindowType)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::unmap_event_impl(_GdkEventAny*)' ./libomnijobdialog.so: undefined reference to `Gtk::Entry::Entry()' ./libomnijobdialog.so: undefined reference to `Gtk::QuitSig::callback(void*)' ./libomnijobdialog.so: undefined reference to `Gtk::Button::signal_names' ./libomnijobdialog.so: undefined reference to `Gtk::Table::attach(Gtk::Widget&, unsigned, unsigned, unsigned, unsigned, int, int, unsigned, unsigned)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::~Widget()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::drag_data_delete_impl(_GdkDragContext*)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::~Widget()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::show_all_impl()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::visibility_notify_event_impl(_GdkEventVisibility*)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::motion_notify_event_impl(_GdkEventMotion*)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::no_expose_event_impl(_GdkEventAny*)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::hide_impl()' ./libomnijobdialog.so: undefined reference to `SigC::SlotDependent::~SlotDependent()' ./libomnijobdialog.so: undefined reference to `Gtk::ButtonBox::set_child_size(int, int)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::selection_get_impl(_GtkSelectionData*, unsigned, unsigned)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::enter_notify_event_impl(_GdkEventCrossing*)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::hide_all_impl()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::key_press_event_impl(_GdkEventKey*)' ./libomnijobdialog.so: undefined reference to `SigC::Object::~Object()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::selection_request_event_impl(_GdkEventSelection*)' ./libomnijobdialog.so: undefined reference to `vtable for SigC::Scope' ./libomnijobdialog.so: undefined reference to `virtual thunk to Gtk::Container::~Container()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::unmap__impl()' ./libomnijobdialog.so: undefined reference to `Gtk::Combo::isA(Gtk::Object*)' ./libomnijobdialog.so: undefined reference to `virtual thunk to SigC::Object::~Object()' ./libomnijobdialog.so: undefined reference to `Gtk::Entry::set_text(std::string const&)' ./libomnijobdialog.so: undefined reference to `Gtk::Container::add(Gtk::Widget&)' ./libomnijobdialog.so: undefined reference to `Gtk::Entry::isA(Gtk::Object*)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::size_allocate_impl(_GtkAllocation*)' ./libomnijobdialog.so: undefined reference to `virtual thunk to Gtk::Bin::~Bin()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::map__impl()' ./libomnijobdialog.so: undefined reference to `SigC::ObjectReferenced::reference()' ./libomnijobdialog.so: undefined reference to `Gtk::nstring::nstring(std::string)' ./libomnijobdialog.so: undefined reference to `SigC::ObjectReferenced::unreference()' ./libomnijobdialog.so: undefined reference to `Gtk::Container::set_border_width(unsigned)' ./libomnijobdialog.so: undefined reference to `Gtk::Base::~Base()' ./libomnijobdialog.so: undefined reference to `SigC::ObjectReferenced::set_dynamic()' ./libomnijobdialog.so: undefined reference to `Gtk::Bin::~Bin()' ./libomnijobdialog.so: undefined reference to `Gtk::Container::check_resize_impl()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::parent_changed_impl(Gtk::Widget*)' ./libomnijobdialog.so: undefined reference to `vtable for SigC::SlotData' ./libomnijobdialog.so: undefined reference to `virtual thunk to Gtk::Base::~Base()' ./libomnijobdialog.so: undefined reference to `Gtk::ButtonBox::set_spacing(int)' ./libomnijobdialog.so: undefined reference to `virtual thunk to Gtk::Base::~Base()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::drag_motion_impl(_GdkDragContext*, int, int, unsigned)' ./libomnijobdialog.so: undefined reference to `Gtk::Table::Table(int, int, int)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::state_changed_impl(GtkStateType)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::selection_clear_event_impl(_GdkEventSelection*)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::selection_received_impl(_GtkSelectionData*, unsigned)' ./libomnijobdialog.so: undefined reference to `Gtk::Entry::get_text() const' ./libomnijobdialog.so: undefined reference to `SigC::Scopes::Extend::set(SigC::ObjectScoped*, void*, bool)' ./libomnijobdialog.so: undefined reference to `Gtk::Bin::~Bin()' ./libomnijobdialog.so: undefined reference to `Gtk::Window::~Window()' ./libomnijobdialog.so: undefined reference to `Gtk::Object::set_dynamic()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::property_notify_event_impl(_GdkEventProperty*)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::focus_in_event_impl(_GdkEventFocus*)' ./libomnijobdialog.so: undefined reference to `virtual thunk to Gtk::Window::~Window()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::draw_default_impl()' ./libomnijobdialog.so: undefined reference to `virtual thunk to Gtk::Widget::~Widget()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::button_press_event_impl(_GdkEventButton*)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::grab_focus_impl()' ./libomnijobdialog.so: undefined reference to `Gtk::nstring::~nstring()' ./libomnijobdialog.so: undefined reference to `SigC::Object::~Object()' ./libomnijobdialog.so: undefined reference to `SigC::SlotList_::clear()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::debug_msg_impl(char const*)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::drag_leave_impl(_GdkDragContext*, unsigned)' ./libomnijobdialog.so: undefined reference to `Gtk::Container::set_focus_child_impl(Gtk::Widget*)' ./libomnijobdialog.so: undefined reference to `Gtk::Window::~Window()' ./libomnijobdialog.so: undefined reference to `SigC::ObjectScoped::register_data(SigC::ScopeNode*)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::selection_notify_event_impl(_GdkEventSelection*)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::key_release_event_impl(_GdkEventKey*)' ./libomnijobdialog.so: undefined reference to `Gtk::Object::reference()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::map_event_impl(_GdkEventAny*)' ./libomnijobdialog.so: undefined reference to `virtual thunk to Gtk::Object::~Object()' ./libomnijobdialog.so: undefined reference to `Gtk::Object::~Object()' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::focus_out_event_impl(_GdkEventFocus*)' ./libomnijobdialog.so: undefined reference to `Gtk::ScrolledWindow::add_with_viewport(Gtk::Widget&)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::drag_drop_impl(_GdkDragContext*, int, int, unsigned)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::drag_end_impl(_GdkDragContext*)' ./libomnijobdialog.so: undefined reference to `Gtk::ScrolledWindow::set_policy(GtkPolicyType, GtkPolicyType)' ./libomnijobdialog.so: undefined reference to `Gtk::Widget::drag_begin_impl(_GdkDragContext*)' collect2: ld returned 1 exit status make: *** [Tester] Error 1 Mark Take a look at the Linux Omni printer driver at http://www.ibm.com/linux/ltc/projects/omni/ |
|
From: rillian <ri...@te...> - 2002-02-03 21:44:28
|
On 01/31/2002 at 15:58:51 Andrew Evans wrote: > The preprocessor macro __GNUC__ contains the major version number of > the compiler. __GNUC_MINOR__ contains the minor version number of the > compiler, as you'd expect. So you can replace '#ifdef GCC_VER_3' with > '#if defined(__GNUC__) && (__GNUC__ >= 3)', I think. Unfortunately this isn't sufficient. The default compiler on Debian woody calls itself 2.95.4. So this check isn't sufficient. However, building current cvs with -DGCC_VER_3 does repair the link problems I was seeing 'out of the box' with 2.95.4. Just so we're all on the same page, this particular trouble looks like: make[1]: Entering directory `/home/giles/projects/ghostscript/omni/XMLParser' c++ -o parser MyErrorHandler.o OmniDomParser.o Main.o -L .. -lomni -lxml -L/usr/lib -rdynamic -lgmodule -lglib -ldl ../libomni.so: undefined reference to `getEnumeration__Q312OmniPDCProxy38getCurrentResolution__12OmniPDCProxy.0_22OmniPDCProxyResolution.987' [...and many similar undefined references] Building with DEBUG=1 also remedied this. The (__GNUC__ > 3) check does work with gcc-3.0, but there appear to additional source gotchas: g++-3.0 -Wall -fPIC -rdynamic -O3 -DRETAIL=1 -I . -I hppcl3 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -c DeviceBlitter.cpp In file included from DeviceBlitter.cpp:19: Device.hpp:141: type specifier omitted for parameter Device.hpp:141: parse error before `)' token make: *** [DeviceBlitter.o] Error 1 I hope we can get this cleared up and building more portably soon. Cheers, -ralph |
|
From: Patrick P. <pap...@as...> - 2002-02-01 03:04:25
|
> From rl...@ti... Thu Jan 24 04:24:40 2002 > Date: Thu, 24 Jan 2002 07:18:55 -0500 > From: Robert L Krawitz <rl...@al...> > To: pap...@as... > CC: pri...@fr..., ink...@li..., > omn...@li..., > omn...@li..., pri...@fr..., > pz...@us... > Subject: Re: [Inkjet-list] Thoughts on Drivers, Early and Late Binding, When to Do Conversion > > Date: Tue, 22 Jan 2002 15:56:48 -0800 (PST) > From: Patrick Powell <pap...@as...> > > a) Bind the 'graphical image size' as early as possible. > That is, generate your print jobs with intimate knowledge > of the graphical image size. > > This means: > 'select page size and printable area first' > > b) Do paper or media selection as LATE as possible. > That is, pass requests for paper type, paper size > (actually, you may need to do this together with a)), > duplex, finishing, etc., as late as possible. > > This means: > 'do not embed these options in the output from a)' > > The printable area may depend upon these parameters. For example, the > printable area when printing on an 8.5x11 piece of roll-fed paper is > typically different from that on sheetfed paper. > > -- > 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 Gimp Print/stp -- http://gimp-print.sourceforge.net > > "Linux doesn't dictate how I work, I dictate how Linux works." > --Eric Crampton > Right. No question about it. I said that this is a preference, and not an absolute requirement. If you are in need of 'absolute printable area and the real location on the page at print time' then you will have to borrow the IPP method: send a job to the printer with a 'request', get back a set of 'configuration values' for the job, which will tell you what various things will be done. Of course, for most purposes (99.99995%) this will be overkill... But it is still important. The other method is to brutally create a special 'printer' that simulates the actions of the 'print on roll paper' and have it fake the parameters. This is once again an example where EARLY BINDING is necessary, but you will need to bind all of the stuff at job submission time. Patrick Powell Astart Technologies, pap...@as... 9475 Chesapeake Drive, Suite D, Network and System San Diego, CA 92123 Consulting 858-874-6543 FAX 858-279-8424 LPRng - Print Spooler (http://www.lprng.com) |
|
From: Andrew E. <lit...@ya...> - 2002-01-31 23:59:15
|
Mark Hamzy <ha...@us...> wrote: > Ok. I have put the latest files in cvs. It does compile now with the > command: > make CFLAGS="-march=i386 -mcpu=i686 -Wall -DGCC_VER_3" Excellent. I have pulled the latest and am building. > Now, all I need is a way to determine which version of the compiler > that I am using instead of using an external define (GCC_VER_3). The preprocessor macro __GNUC__ contains the major version number of the compiler. __GNUC_MINOR__ contains the minor version number of the compiler, as you'd expect. So you can replace '#ifdef GCC_VER_3' with '#if defined(__GNUC__) && (__GNUC__ >= 3)', I think. -Andrew |
|
From: rillian <ri...@te...> - 2002-01-31 05:03:49
|
On Wed, 23 Jan 2002, our fearless leader wrote: The Omni.patch.090501.clean patch is not suitable as is for a Ghostscript release. Basically, the patches have to be localized to the unix-gcc.mak toplevel makefile. The patches you've made to ugcclib.mak, and unixlink.mak would rather dramatically break the build for other platforms. Here's a basic stab at the integration. It's not finished; in particular the load of libomni.so fails due to missing symbols, so the build isn't quite right, though that could certainly be on the Omni side, rather than with ghostscript. This patch updates gomni.c to the version from Omni-0.5.1 (the 090501.clean patch) and adds some rough support for building it to the makefiles. The tricky bit is that Omni now depends on glib, building against which pretty much requires glib-config calls on the command line. One option would be to add -compileliteral, and -linkliteral .dev args to genconf. What we do here is use a bit of sed to strip out the linker command options and pass that from the toplevel makefile so genconf can put them back in. We cheat on the cflags and pass them directly, since there's no similar mechanism of -I lines. $(I) and friends should be handled by glib-config on any platform we'll be able to build this on anyway, so I think we lose no portability there. The patch is against GS_6_5, but is intended for all branches. It also does some rearrangement in contrib.mak. Sorry for the noise. TODO: port the device documentation from Omni.readme.1st fix linker options FWIW, -r |
|
From: Mark H. <ha...@us...> - 2002-01-30 23:45:15
|
Ok. I have put the latest files in cvs. It does compile now with the
command:
make CFLAGS="-march=i386 -mcpu=i686 -Wall -DGCC_VER_3"
Now, all I need is a way to determine which version of the compiler that I
am using instead of using
an external define (GCC_VER_3).
Thanks Tim for your help.
Mark
Take a look at the Linux Omni printer driver at
http://www.ibm.com/linux/ltc/projects/omni/
|
|
From: Tim W. <tw...@re...> - 2002-01-25 23:09:51
|
On Fri, Jan 25, 2002 at 03:16:17PM -0600, Mark Hamzy wrote:
> I am running into the following problems. Can you help?
>=20
> The missing gcc_s also affects other programs. What package is this in?
I think that's in libgcc.
> OmniProxy.cpp:1215: insn does not satisfy its constraints:
> (insn 2855 1721 2861 (set (mem:QI (plus:SI (reg/f:SI 6 ebp)
> (const_int -284 [0xfffffee4])) [79 S1 A32])
> (reg:QI 4 sil)) 60 {*movqi_1} (nil)
> (nil))
> OmniPDCProxy.cpp:1788: internal error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://bugzilla.redhat.com/bugzilla/> for instructions.
I also encountered compiler bugs (they are in Bugzilla). Try with
'-O2 -march=3Di386 -mcpu=3Di686'. Now you see why I made a patch to make
CFLAGS easily adjustable. :-)
Tim.
*/
|
|
From: Mark H. <ha...@us...> - 2002-01-25 21:17:43
|
Hey Tim,
I am running into the following problems. Can you help?
The missing gcc_s also affects other programs. What package is this in?
[hamzy@hamzy3 Omni.C++]$ c++ test.cpp
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
c++ -fPIC -Wall -O3 -DRETAIL=1 -I . -I hppcl3 -I/usr/include/glib-1.2
-I/usr/lib/glib/include -c OmniProxy.cpp
OmniProxy.cpp: In member function `void OmniProxy::replayBitmaps()':
OmniProxy.cpp:1215: insn does not satisfy its constraints:
(insn 2855 1721 2861 (set (mem:QI (plus:SI (reg/f:SI 6 ebp)
(const_int -284 [0xfffffee4])) [79 S1 A32])
(reg:QI 4 sil)) 60 {*movqi_1} (nil)
(nil))
OmniProxy.cpp:1215: Internal compiler error in
reload_cse_simplify_operands, at reload1.c:8345
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla/> for instructions.
make: *** [OmniProxy.o] Error 1
c++ -fPIC -Wall -O3 -DRETAIL=1 -I . -I hppcl3 -I/usr/include/glib-1.2
-I/usr/lib/glib/include -c OmniPDCProxy.cpp
OmniPDCProxy.cpp: In static member function `static DeviceResolution*
DeviceResolution*
OmniPDCProxy::getCurrentResolution
()::OmniPDCProxyResolution::create(char*,
PrinterCommand*, int, int)':
OmniPDCProxy.cpp:1788: internal error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla/> for instructions.
make: *** [OmniPDCProxy.o] Error 1
Mark
Take a look at the Linux Omni printer driver at
http://www.ibm.com/linux/ltc/projects/omni/
|
|
From: Mark H. <ha...@us...> - 2002-01-24 17:11:27
|
Hey all, I have taken in Tim's patches except for the file handle stuff. I am in the process of setting up another machine so that I can install the latest gcc. I will redesign the omni for the file stuff. Thanks, Mark Take a look at the Linux Omni printer driver at http://www.ibm.com/linux/ltc/projects/omni/ |
|
From: Robert L K. <rl...@al...> - 2002-01-24 17:01:05
|
Date: Tue, 22 Jan 2002 15:56:48 -0800 (PST)
From: Patrick Powell <pap...@as...>
a) Bind the 'graphical image size' as early as possible.
That is, generate your print jobs with intimate knowledge
of the graphical image size.
This means:
'select page size and printable area first'
b) Do paper or media selection as LATE as possible.
That is, pass requests for paper type, paper size
(actually, you may need to do this together with a)),
duplex, finishing, etc., as late as possible.
This means:
'do not embed these options in the output from a)'
The printable area may depend upon these parameters. For example, the
printable area when printing on an 8.5x11 piece of roll-fed paper is
typically different from that on sheetfed paper.
--
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 Gimp Print/stp -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
|
|
From: Tim W. <tw...@re...> - 2002-01-24 09:09:32
|
On Wed, Jan 23, 2002 at 08:22:07PM -0800, Andrew Evans wrote: > I will fix this and keep moving on, but this is getting tedious. Does > anyone out there have patches or hints on how to get Omni compiled > with either of these gcc/g++ versions? I posted them to this very list just days ago. Tim. */ |
|
From: Andrew E. <lit...@ya...> - 2002-01-24 04:22:09
|
I'm trying to get Omni (from CVS head) compiled on my Debian Linux box. First tried building with gcc 2.95.4 (this was before discovering docs/Omni.readme.1st). That didn't work because of the documented problem of non-external linkage of member functions in nested class definitions. (Is there a switch to get around this? I couldn't find one.) So I installed gcc 3.0.3, since that is the only other version of gcc in Debian woody at the moment. This produces reams of compile errors, mostly because none of the Omni source references C++ standard template library classes via the std:: namespace. And the gcc team evidently got rid of -fno-honor-std recently, so I've sprinkled 'using namespace std;' about the places that needed it. But now I've hit something more difficult: PrintDevice.cpp fails to compile. PrintDevice::setOutputStream() tries to instantiate a std::filebuf object from an integer (i.e. created by UNIX's open()) file descriptor. Evidently the libstdc++ that ships with gcc 3.0.3 doesn't support this any more; the choices are another filebuf object or a stdio FILE*. I will fix this and keep moving on, but this is getting tedious. Does anyone out there have patches or hints on how to get Omni compiled with either of these gcc/g++ versions? thanks for any help you can provide, -Andrew |
|
From: Patrick P. <pap...@as...> - 2002-01-22 23:56:59
|
Due to time problems, I have not been an active submitter to this
list. I would like to make some comments on some topics that have
been under discussions.
WHAT IS A DRIVER?
The problem here is that the term 'driver' is a semantically loaded
word. In the Microsoft Windows environment, printing is done VIA
a 'printer device', which just happens to look very similar from
an IO standpoint to a real device. You can send data to the device
(well, anybody with any sanity will use the graphics library:-),
and there are a well supported set of IO operations API's defined
to support them as well.
But you are really doing IO operations that magically get translated
into stuff in a file that is then sent to a printer.
To make things work right, you need to get device parameters and
discover the magic things that need to be done in what order. Most
of the work of the API library support is making this job easier
for the user.
One way to 'simplify' UNIX printing is to clone this type of
operation: come up with a standard set of 'drawing operations'
and you are finished.
This is REALLY REALLY appealing. In fact, several systems have
been designed and papers written on how to do this in the UNIX
environment. In fact, some folks tried to do this VIA the X
environment, by setting up a virtual X device that was such a
printer. So.... all we need to do is extend the X Server so that
it has:
a) Open a print job
b) Set the 'visual characteristics' of the current 'page image'
c) Get the 'visual characteristics' of the current 'page image'
d) Throw crud on the screen^H^H^H^H^H 'page image'
e) Finish/terminate the current page
f) Finish/terminate the current 'print job'
g) Commit the print job to the 'printer'
The 'driver API' can then simply be the set of X library functions
that do low level graphics operations, extended by the various
printing stuff.
EARLY BINDING and LATE BINDING
The big headache in printing is trying to decide how and when
to bind your printing job image to the printer.
Early binding:
At the time of 'print job submission' you do absolutely everything
to nail the job/output/format/whatever to the output device.
You can, given knowlege of the communications channel to the device,
do various things in real time, such as request paper to be loaded,
operator to put covers into printer, etc.
Disadvantages:
This requires that as much information as possible, including
all raster conversions, data formats, communication channel
operations, etc., be known to the 'early binding' process.
Advantages:
The print job generator can take advantage of special device options
that are available to her.
Late Binding:
As little as possible is done to make the print job depend on the
output device. In fact, some sort of 'generic print job' format
is used, and then the last stage in the printing process will
convert this to the output format and/or commands compatible
with a specific printer.
Disadvantages:
You need a special 'generic language' that does not depend
on the printer, and conventions about 'format requests'
and 'print job options' to be passed as part of the print
job.
Advantages:
You do not need to have intimate knowledge of the printer,
just of the &*(()*& 'generic language'.
What is Best?
That depends on what you are doing. HOWEVER... I like the
following:
a) Bind the 'graphical image size' as early as possible.
That is, generate your print jobs with intimate knowledge
of the graphical image size.
This means:
'select page size and printable area first'
b) Do paper or media selection as LATE as possible.
That is, pass requests for paper type, paper size
(actually, you may need to do this together with a)),
duplex, finishing, etc., as late as possible.
This means:
'do not embed these options in the output from a)'
c) Do rasterization, font selection, etc. etc., at the most
appropriate point. This can be done AFTER a) or AFTER b)
Initial Submission Does Raster
NEED: page size (generate image + rasterize)
OUTPUT: 'raster for device'
-> Late binding media selection stuff
-> device
Note - this makes a lot of sense for devices that
do not do rasterization or whose basic rasterization
stuff is terrible.
Example:
Images -> raster for some printers
(Gimp folks do a great job here)
Initial Submission Does Generic
NEED: page size (generate image in 'generic format')
OUTPUT: 'generic format'
-> Late binding media selection stuff
-> device
-> device does rasterization
Example:
text -> PostScript
(Font definiitions added to the job)
-> Late binding media selection stuff
-> device
Postscript interpreter in device
does rasterization
But really, we want the ability to do both:
Initial Submission Does Generic +
Middle Does Raster
NEED: page size (generate image in 'generic format')
OUTPUT: 'generic format'
-> Raster converter and fixer upper
-> Late binding media selection stuff
-> device
This is the model that is used for most GhostScript
based converters - you generate the job in PostScript,
fling it at a conversion system^H^H^H^H^H^H print spooler,
the conversion system does the rasterization based on the
output device it will choose to print the job on,
and then send it to the device.
I think that there is a need to support all three of these
models in whatever folks propose.
Patrick Powell Astart Technologies,
pap...@as... 9475 Chesapeake Drive, Suite D,
Network and System San Diego, CA 92123
Consulting 858-874-6543 FAX 858-279-8424
LPRng - Print Spooler (http://www.lprng.com)
|
|
From: Tim W. <tw...@re...> - 2002-01-22 15:46:25
|
This patch removes include path directives from CFLAGS and puts them in INCLUDES, so that CFLAGS can be substituted on the command line like: make retail=1 CFLAGS="-O2 -march=i386 -mcpu=i686" Tim. */ --- Omni/CUPS/Makefile.cflags Wed Jun 13 20:23:08 2001 +++ Omni/CUPS/Makefile Tue Jan 22 14:16:30 2002 @@ -37,16 +37,18 @@ else CFLAGS = endif -CFLAGS += -Wall $(OMNI_INCLUDE_PATH) +CFLAGS += -Wall ifdef DEBUG CFLAGS += -g -DDEBUG=1 endif +INCLUDES := +INCLUDES += $(OMNI_INCLUDE_PATH) .SUFFIXES: .SUFFIXES: .cpp .hpp .o .exe .cpp.o: - $(CC) $(CFLAGS) -c $(*F).cpp + $(CC) $(CFLAGS) $(INCLUDES) -c $(*F).cpp % : %.cpp $(CC) $(CFLAGS) -o $(*F) $(OMNI_LIB_PATH) $(OMNI_LIBS) $(CUPS_LIB_PATH) $(CUPS_LIBS) $(*F).cpp @@ -59,7 +61,7 @@ # on the source files and if those files change, then new dependancies # need to be made and reloaded ifeq "$(shell test ! -f depend.mak && echo yes)" "yes" -ifeq "$(shell $(CC) $(CFLAGS) -M *.cpp > depend.mak)" "" +ifeq "$(shell $(CC) $(CFLAGS) $(INCLUDES) -M *.cpp > depend.mak)" "" endif endif include depend.mak --- Omni/XMLParser/libxml/Makefile.cflags Fri Nov 16 21:23:39 2001 +++ Omni/XMLParser/libxml/Makefile Tue Jan 22 14:16:30 2002 @@ -44,19 +44,21 @@ else CFLAGS = endif -CFLAGS += -Wall -I $(OMNI_INCLUDE_PATH) +CFLAGS += -Wall ifneq ($(strip $(DEBUG)),) CFLAGS += -g -DDEBUG=1 else CFLAGS += -O3 endif +INCLUDES := +INCLUDES += -I $(OMNI_INCLUDE_PATH) LFLAGS = -L $(OMNI_LIB_PATH) $(OMNI_LIBS) $(XML_LIBS) $(shell glib-config --libs gmodule) .SUFFIXES: .SUFFIXES: .cpp .hpp .o .exe .cpp.o: - $(CC) $(CFLAGS) -c $(*F).cpp + $(CC) $(CFLAGS) $(INCLUDES) -c $(*F).cpp all: parser @@ -91,7 +93,7 @@ # on the source files and if those files change, then new dependancies # need to be made and reloaded ifeq "$(shell test ! -f depend.mak && echo yes)" "yes" -ifeq "$(shell $(CC) $(CFLAGS) -M $(PARSER_CFILES:~=.cpp) > depend.mak)" "" +ifeq "$(shell $(CC) $(CFLAGS) $(INCLUDES) -M $(PARSER_CFILES:~=.cpp) > depend.mak)" "" endif endif include depend.mak --- Omni/XMLParser/xerces-c1_3_0-linux/Makefile.cflags Fri Nov 16 21:23:41 2001 +++ Omni/XMLParser/xerces-c1_3_0-linux/Makefile Tue Jan 22 14:16:30 2002 @@ -49,19 +49,21 @@ else CFLAGS = endif -CFLAGS += -Wall -I $(XML_INCLUDE_PATH) -I $(OMNI_INCLUDE_PATH) +CFLAGS += -Wall ifneq ($(strip $(DEBUG)),) CFLAGS += -g -DDEBUG=1 else CFLAGS += -O3 endif +INCLUDES := +INCLUDES += -I $(XML_INCLUDE_PATH) -I $(OMNI_INCLUDE_PATH) LFLAGS = -L $(OMNI_LIB_PATH) $(OMNI_LIBS) -L $(XML_LIB_PATH) $(XML_LIBS) $(shell glib-config --libs gmodule) .SUFFIXES: .SUFFIXES: .cpp .hpp .o .exe .cpp.o: - $(CC) $(CFLAGS) -c $(*F).cpp + $(CC) $(CFLAGS) $(INCLUDES) -c $(*F).cpp all: parser @@ -96,7 +98,7 @@ # on the source files and if those files change, then new dependancies # need to be made and reloaded ifeq "$(shell test ! -f depend.mak && echo yes)" "yes" -ifeq "$(shell $(CC) $(CFLAGS) -M $(PARSER_CFILES:~=.cpp) > depend.mak)" "" +ifeq "$(shell $(CC) $(CFLAGS) $(INCLUDES) -M $(PARSER_CFILES:~=.cpp) > depend.mak)" "" endif endif include depend.mak --- Omni/XMLParser/xml4c3_1_0-linux/Makefile.cflags Fri Nov 16 21:23:43 2001 +++ Omni/XMLParser/xml4c3_1_0-linux/Makefile Tue Jan 22 14:16:30 2002 @@ -45,17 +45,19 @@ else CFLAGS = endif -CFLAGS += -Wall -I $(XML_INCLUDE_PATH) -I $(OMNI_INCLUDE_PATH) +CFLAGS += -Wall ifdef DEBUG CFLAGS += -g -DDEBUG=1 endif +INCLUDES := +INCLUDES += -I $(XML_INCLUDE_PATH) -I $(OMNI_INCLUDE_PATH) LFLAGS = -L $(OMNI_LIB_PATH) $(OMNI_LIBS) -L $(XML_LIB_PATH) $(XML_LIBS) $(shell glib-config --libs gmodule) .SUFFIXES: .SUFFIXES: .cpp .hpp .o .exe .cpp.o: - $(CC) $(CFLAGS) -c $(*F).cpp + $(CC) $(CFLAGS) $(INCLUDES) -c $(*F).cpp all: parser @@ -90,7 +92,7 @@ # on the source files and if those files change, then new dependancies # need to be made and reloaded ifeq "$(shell test ! -f depend.mak && echo yes)" "yes" -ifeq "$(shell $(CC) $(CFLAGS) -M $(PARSER_CFILES:~=.cpp) > depend.mak)" "" +ifeq "$(shell $(CC) $(CFLAGS) $(INCLUDES) -M $(PARSER_CFILES:~=.cpp) > depend.mak)" "" endif endif include depend.mak --- Omni/XMLParser/Makefile.cflags Fri Nov 16 21:23:42 2001 +++ Omni/XMLParser/Makefile Tue Jan 22 14:16:30 2002 @@ -44,19 +44,21 @@ else CFLAGS = endif -CFLAGS += -Wall -I $(OMNI_INCLUDE_PATH) +CFLAGS += -Wall ifneq ($(strip $(DEBUG)),) CFLAGS += -g -DDEBUG=1 else CFLAGS += -O3 endif +INCLUDES := +INCLUDES += -I $(OMNI_INCLUDE_PATH) LFLAGS = -L $(OMNI_LIB_PATH) $(OMNI_LIBS) $(XML_LIBS) $(shell glib-config --libs gmodule) .SUFFIXES: .SUFFIXES: .cpp .hpp .o .exe .cpp.o: - $(CC) $(CFLAGS) -c $(*F).cpp + $(CC) $(CFLAGS) $(INCLUDES) -c $(*F).cpp all: parser @@ -91,7 +93,7 @@ # on the source files and if those files change, then new dependancies # need to be made and reloaded ifeq "$(shell test ! -f depend.mak && echo yes)" "yes" -ifeq "$(shell $(CC) $(CFLAGS) -M $(PARSER_CFILES:~=.cpp) > depend.mak)" "" +ifeq "$(shell $(CC) $(CFLAGS) $(INCLUDES) -M $(PARSER_CFILES:~=.cpp) > depend.mak)" "" endif endif include depend.mak --- Omni/UPDF/Makefile.cflags Thu Aug 16 22:35:51 2001 +++ Omni/UPDF/Makefile Tue Jan 22 14:16:30 2002 @@ -45,19 +45,21 @@ else CFLAGS = endif -CFLAGS += -Wall -I $(OMNI_INCLUDE_PATH) +CFLAGS += -Wall ifdef DEBUG CFLAGS += -g -DDEBUG=1 endif ifneq ($(origin USE_DYNAMIC_LINKING), undefined) CFLAGS += -DUSE_DYNAMIC_LINKING=1 endif +INCLUDES := +INCLUDES += -I $(OMNI_INCLUDE_PATH) .SUFFIXES: .SUFFIXES: .cpp .hpp .o .exe .cpp.o: - $(CC) $(CFLAGS) -c $(*F).cpp + $(CC) $(CFLAGS) $(INCLUDES) -c $(*F).cpp all: UPDFConverter ParameterConverterTester @@ -104,7 +106,7 @@ # on the source files and if those files change, then new dependancies # need to be made and reloaded ifeq "$(shell test ! -f depend.mak && echo yes)" "yes" -ifeq "$(shell $(CC) $(CFLAGS) -M $(PARSER_CFILES:~=.cpp) > depend.mak)" "" +ifeq "$(shell $(CC) $(CFLAGS) $(INCLUDES) -M $(PARSER_CFILES:~=.cpp) > depend.mak)" "" endif endif include depend.mak --- Omni/Foomatic/Makefile.cflags Tue Jan 22 15:13:23 2002 +++ Omni/Foomatic/Makefile Tue Jan 22 15:13:24 2002 @@ -50,7 +50,7 @@ # on the source files and if those files change, then new dependancies # need to be made and reloaded ifeq "$(shell test ! -f depend.mak && echo yes)" "yes" -ifeq "$(shell $(CC) $(CFLAGS) -M $(FOOMATIC_FILES:~=.cpp) > depend.mak)" "" +ifeq "$(shell $(CC) $(CFLAGS) $(INCLUDES) -M $(FOOMATIC_FILES:~=.cpp) > depend.mak)" "" endif endif include depend.mak --- Omni/Makefile.cflags Tue Jan 22 14:16:30 2002 +++ Omni/Makefile Tue Jan 22 14:16:30 2002 @@ -94,7 +94,8 @@ else CFLAGS += -O3 endif -CFLAGS += $(shell glib-config --cflags gmodule) +INCLUDES := +INCLUDES += $(shell glib-config --cflags gmodule) LFLAGS = -L . -l$(LIBRARYNAME) $(shell glib-config --libs gmodule) include version.mak @@ -103,7 +104,7 @@ .SUFFIXES: .cpp .hpp .o .exe .cpp.o: - $(CC) $(CFLAGS) -c $(*F).cpp + $(CC) $(CFLAGS) $(INCLUDES) -c $(*F).cpp all: sharedlibrary subdirs exes @@ -152,7 +153,7 @@ # on the source files and if those files change, then new dependancies # need to be made and reloaded ifeq "$(shell test ! -f depend.mak && echo yes)" "yes" -ifeq "$(shell $(CC) $(CFLAGS) -M $(DEVHELPERFILES:~=.cpp) OmniServer.cpp > depend.mak)" "" +ifeq "$(shell $(CC) $(CFLAGS) $(INCLUDES) -M $(DEVHELPERFILES:~=.cpp) OmniServer.cpp > depend.mak)" "" endif endif include depend.mak --- Omni/common.mak.cflags Fri Nov 16 21:23:44 2001 +++ Omni/common.mak Tue Jan 22 14:16:30 2002 @@ -54,14 +54,16 @@ DEBUG = RETAIL = retail=1 endif -CFLAGS = -Wall -I .. -I . -I ../hppcl3 +CFLAGS = -Wall ifneq ($(strip $(DEBUG)),) CFLAGS += -g -DDEBUG=1 else CFLAGS += -O3 endif CFLAGS += -fPIC -rdynamic -CFLAGS += $(shell glib-config --cflags gmodule) +INCLUDES := +INCLUDES += -I .. -I . -I ../hppcl3 +INCLUDES += $(shell glib-config --cflags gmodule) LFLAGS = -L $(OMNI_LIB_PATH) -l$(LIBRARYNAME) $(shell glib-config --libs gmodule) include $(OMNI_PATH)/version.mak @@ -70,7 +72,7 @@ .SUFFIXES: .cpp .hpp .o .exe .cpp.o: - $(CC) $(CFLAGS) -c $(*F).cpp + $(CC) $(CFLAGS) $(INCLUDES) -c $(*F).cpp ifeq ($(origin DEVICENAME), undefined) notall: # This should not be called by itself! |
|
From: Tim W. <tw...@re...> - 2002-01-22 15:37:18
|
..and here is the patch.
BinaryData.hpp | 2 ++
DeviceConnection.hpp | 2 ++
DeviceGamma.hpp | 2 ++
Foomatic/omni2foo.cpp | 2 +-
Foomatic/omni2foo.hpp | 2 ++
GhostscriptInterface.cpp | 39 ++++++++++++++++++++-------------------
Makefile | 9 +++++----
OmniProxy.cpp | 1 +
PrintDevice.cpp | 25 +++++++++++++++++++++++--
PrintDevice.hpp | 1 +
PrinterCommand.cpp | 3 +++
XMLParser/DeviceInfo.hpp | 2 ++
hppcl3/CMYKbitmap.cpp | 2 ++
hppcl3/bitmap.cpp | 5 ++++-
14 files changed, 70 insertions(+), 27 deletions(-)
The two larger changes are:
- GhostscriptInterface.cpp: Due to the ISO resolution of defect report
50, you can no longer do things like 'cerr = fcerr;'. This
work-around is probably a bit of a sledge-hammer and there is sure
to be an easier way around it.
- PrintDevice.cpp:
a) there is no filebuf(int fd) constructor any more, but you can now
construct a filebuf from a FILE* and ios modes (this is still
non-standard). So, do that. NOTE: unfortunately, this won't work
on older versions of libstdc++. Long-term fix would be not to start
from a file descriptor..
b) char* vs unsigned char*: I just put a cast in for now.
Still unresolved:
Lots of the DeviceTester files have similar sorts of problems as
GhostscriptInterface.cpp did: assignments to cerr and the like.
--- Omni/XMLParser/DeviceInfo.hpp.gcc31 Fri Nov 16 21:23:46 2001
+++ Omni/XMLParser/DeviceInfo.hpp Tue Jan 22 14:16:30 2002
@@ -23,6 +23,8 @@
#include <map>
#include <list>
+using namespace std;
+
typedef list <string> OrientationList;
typedef list <string> ResolutionList;
typedef list <string> PrintModeList;
--- Omni/hppcl3/bitmap.cpp.gcc31 Thu Mar 1 22:55:00 2001
+++ Omni/hppcl3/bitmap.cpp Tue Jan 22 14:16:30 2002
@@ -22,6 +22,9 @@
#include <unistd.h>
#include <memory.h>
#include <iostream.h>
+#include <algorithm>
+
+using std::min;
const static bool fDebugOutput = false;
@@ -395,7 +398,7 @@
while (iPos < iSize)
{
- rc = write (fileno, abData, min ((iSize - iPos), (int)sizeof (abData)));
+ rc = write (fileno, abData, min ((iSize - iPos), (long int)sizeof (abData)));
if (-1 == rc)
return rc;
--- Omni/hppcl3/CMYKbitmap.cpp.gcc31 Thu Mar 1 22:55:00 2001
+++ Omni/hppcl3/CMYKbitmap.cpp Tue Jan 22 14:16:30 2002
@@ -23,6 +23,8 @@
#include <memory.h>
#include <iostream.h>
+using std::dec;
+
const static bool fDebugOutput = false;
extern int chsize (int fileno, long int iSize);
--- Omni/Foomatic/omni2foo.hpp.gcc31 Thu Sep 20 18:53:36 2001
+++ Omni/Foomatic/omni2foo.hpp Tue Jan 22 14:16:30 2002
@@ -41,6 +41,8 @@
#include <algorithm> // used for the to lower transform
#include <cctype>
+using namespace std;
+
typedef map<string,string> printerMap;
class omni2foo
{
--- Omni/Foomatic/omni2foo.cpp.gcc31 Fri Nov 16 21:23:40 2001
+++ Omni/Foomatic/omni2foo.cpp Tue Jan 22 14:16:30 2002
@@ -66,7 +66,7 @@
// lowercase all characters
transform (printerName.begin(), printerName.end(), // source
printerName.begin(), // destination
- tolower); // operation
+ ::tolower); // operation
return _mPrinterMap[printerName];
}
--- Omni/BinaryData.hpp.gcc31 Thu Mar 1 22:54:45 2001
+++ Omni/BinaryData.hpp Tue Jan 22 14:16:30 2002
@@ -23,6 +23,8 @@
#include "defines.hpp"
+using namespace std;
+
class BinaryData
{
public:
--- Omni/DeviceConnection.hpp.gcc31 Thu Mar 1 22:54:45 2001
+++ Omni/DeviceConnection.hpp Tue Jan 22 14:16:30 2002
@@ -23,6 +23,8 @@
#include <strstream>
#include <string>
+using namespace std;
+
class DeviceConnection
{
public:
--- Omni/DeviceGamma.hpp.gcc31 Thu Mar 1 22:54:45 2001
+++ Omni/DeviceGamma.hpp Tue Jan 22 14:16:30 2002
@@ -23,6 +23,8 @@
#include <strstream>
#include <string>
+using namespace std;
+
class DeviceGamma {
public:
DeviceGamma (int iCGamma,
--- Omni/OmniProxy.cpp.gcc31 Fri Nov 16 21:23:44 2001
+++ Omni/OmniProxy.cpp Tue Jan 22 14:16:30 2002
@@ -23,6 +23,7 @@
#include <unistd.h>
#include <sys/mman.h>
#include <errno.h>
+#include <stdarg.h>
#include "hppcl3/bitmap.hpp"
--- Omni/PrinterCommand.cpp.gcc31 Thu Sep 20 19:08:58 2001
+++ Omni/PrinterCommand.cpp Tue Jan 22 14:16:30 2002
@@ -20,10 +20,13 @@
#include <string.h>
#include <fstream.h>
#include <unistd.h>
+#include <iostream.h>
#include "PrinterCommand.hpp"
#include "DebugOutput.hpp"
+using namespace std;
+
PrinterCommand::
PrinterCommand (char *pszProgram)
{
--- Omni/PrintDevice.cpp.gcc31 Fri Nov 16 21:23:43 2001
+++ Omni/PrintDevice.cpp Tue Jan 22 14:16:30 2002
@@ -21,6 +21,8 @@
#include <stdarg.h>
#include <string.h>
#include <stdio.h>
+#include <unistd.h>
+#include <fstream>
#include "hppcl3/bitmap.hpp"
@@ -59,6 +61,7 @@
outputStream_d = &cout;
fShouldDeleteOutputStream_d = false;
outputStreamBuf_d = 0;
+ outputStreamFILE_d = 0;
pszDriverName_d = pszDriverName;
pszDeviceName_d = pszDeviceName;
pszShortName_d = pszShortName;
@@ -121,6 +124,12 @@
delete outputStreamBuf_d;
}
+ if (outputStreamFILE_d)
+ {
+ fclose (outputStreamFILE_d);
+ outputStreamFILE_d = 0;
+ }
+
if (pszLoadedLibrary_d)
{
free (pszLoadedLibrary_d);
@@ -1073,13 +1082,25 @@
setOutputStream (ostream *osNew)
{
outputStream_d = osNew;
+ if (outputStreamFILE_d)
+ {
+ fclose (outputStreamFILE_d);
+ outputStreamFILE_d = NULL;
+ }
}
void PrintDevice::
setOutputStream (int iFileNo)
{
- streambuf *sb = new filebuf (iFileNo);
+ int fd = ::dup (iFileNo);
+ FILE *f = fdopen (fd, "w");
+ streambuf *sb = new filebuf (f, ios::out);
outputStream_d = new ostream (sb);
+ if (outputStreamFILE_d)
+ {
+ fclose (outputStreamFILE_d);
+ }
+ outputStreamFILE_d = f;
fShouldDeleteOutputStream_d = true;
}
@@ -1133,7 +1154,7 @@
}
else
{
- outputStream_d->write (pbData, iLength);
+ outputStream_d->write ((const char*) pbData, iLength);
outputStream_d->flush ();
}
--- Omni/GhostscriptInterface.cpp.gcc31 Fri Nov 16 21:23:45 2001
+++ Omni/GhostscriptInterface.cpp Tue Jan 22 14:47:02 2002
@@ -306,12 +306,13 @@
bIJSDevice = false;
// Added for debugging convienence
+ ostream *pcerr = &cerr;
if ( pszCerr
&& pszCerr[0]
)
{
ofstream *fcerr = new ofstream (pszCerr);
- cerr = *fcerr;
+ pcerr = fcerr;
pOutputObject = (void *)fcerr;
}
@@ -322,7 +323,7 @@
#ifndef RETAIL
if (DebugOutput::shouldOutputOmniInterface ())
- cerr << "GhostscriptInterface::" << __FUNCTION__ << ": Trying to load " << cDeviceName << endl;
+ (*pcerr) << "GhostscriptInterface::" << __FUNCTION__ << ": Trying to load " << cDeviceName << endl;
#endif
static char *apszLibraryPaths[] = {
@@ -357,27 +358,27 @@
if (!*pvhDevice)
{
- cerr << endl << "<<<<<<<<<<<<<<<<<<<<<< ERROR >>>>>>>>>>>>>>>>>>>>>>>" << endl;
- cerr << endl << endl;
- cerr << "GhostscriptInterface::" << __FUNCTION__ << ": g_module_error returns " << g_module_error () << endl;
- cerr << "GhostscriptInterface::" << __FUNCTION__ << ": cDeviceName = " << cDeviceName << endl;
- cerr << "GhostscriptInterface::" << __FUNCTION__ << ": pszDeviceName = " << pszDeviceName << endl;
- cerr << endl;
- cerr << "GhostscriptInterface::" << __FUNCTION__ << ": LD_LIBRARY_PATH = " << getenv ("LD_LIBRARY_PATH") << endl;
- cerr << endl;
- cerr << "GhostscriptInterface::" << __FUNCTION__ << ": Omni device library not found in the following paths:" << endl;
+ (*pcerr) << endl << "<<<<<<<<<<<<<<<<<<<<<< ERROR >>>>>>>>>>>>>>>>>>>>>>>" << endl;
+ (*pcerr) << endl << endl;
+ (*pcerr) << "GhostscriptInterface::" << __FUNCTION__ << ": g_module_error returns " << g_module_error () << endl;
+ (*pcerr) << "GhostscriptInterface::" << __FUNCTION__ << ": cDeviceName = " << cDeviceName << endl;
+ (*pcerr) << "GhostscriptInterface::" << __FUNCTION__ << ": pszDeviceName = " << pszDeviceName << endl;
+ (*pcerr) << endl;
+ (*pcerr) << "GhostscriptInterface::" << __FUNCTION__ << ": LD_LIBRARY_PATH = " << getenv ("LD_LIBRARY_PATH") << endl;
+ (*pcerr) << endl;
+ (*pcerr) << "GhostscriptInterface::" << __FUNCTION__ << ": Omni device library not found in the following paths:" << endl;
for (int i = 0; i < (int)dimof (apszLibraryPaths) - 1 && !*pvhDevice; i++)
{
- cerr << "\t" << apszLibraryPaths[i] << "." << endl;
+ (*pcerr) << "\t" << apszLibraryPaths[i] << "." << endl;
}
- cerr << "\t$LD_LIBRARY_PATH" << endl;
+ (*pcerr) << "\t$LD_LIBRARY_PATH" << endl;
return 0;
}
#ifndef RETAIL
if (DebugOutput::shouldOutputOmniInterface ())
- cerr << "GhostscriptInterface::" << __FUNCTION__ << ": *pvhDevice = " << hex << *pvhDevice << dec << endl;
+ (*pcerr) << "GhostscriptInterface::" << __FUNCTION__ << ": *pvhDevice = " << hex << *pvhDevice << dec << endl;
#endif
// nm libHP_Deskjet_1120Cxi.so
@@ -388,12 +389,12 @@
#ifndef RETAIL
if (DebugOutput::shouldOutputOmniInterface ())
- cerr << "GhostscriptInterface::" << __FUNCTION__ << ": pfnNewDevice = 0x" << hex << (int)pfnNewDevice << endl;
+ (*pcerr) << "GhostscriptInterface::" << __FUNCTION__ << ": pfnNewDevice = 0x" << hex << (int)pfnNewDevice << endl;
#endif
if (!pfnNewDevice)
{
- cerr << "GhostscriptInterface::" << __FUNCTION__ << ": g_module_error returns " << dec << g_module_error () << endl;
+ (*pcerr) << "GhostscriptInterface::" << __FUNCTION__ << ": g_module_error returns " << dec << g_module_error () << endl;
return 0;
}
@@ -404,12 +405,12 @@
#ifndef RETAIL
if (DebugOutput::shouldOutputOmniInterface ())
- cerr << "GhostscriptInterface::" << __FUNCTION__ << ": pfnNewDeviceWArgs = 0x" << hex << (int)pfnNewDeviceWArgs << endl;
+ (*pcerr) << "GhostscriptInterface::" << __FUNCTION__ << ": pfnNewDeviceWArgs = 0x" << hex << (int)pfnNewDeviceWArgs << endl;
#endif
if (!pfnNewDeviceWArgs)
{
- cerr << "GhostscriptInterface::" << __FUNCTION__ << ": g_module_error returns " << dec << g_module_error () << endl;
+ (*pcerr) << "GhostscriptInterface::" << __FUNCTION__ << ": g_module_error returns " << dec << g_module_error () << endl;
return 0;
}
@@ -421,7 +422,7 @@
#ifndef RETAIL
if (DebugOutput::shouldOutputOmniInterface ())
- cerr << "GhostscriptInterface::" << __FUNCTION__ << ": pDevice = " << *pDevice_d << endl;
+ (*pcerr) << "GhostscriptInterface::" << __FUNCTION__ << ": pDevice = " << *pDevice_d << endl;
#endif
return pDevice_d;
--- Omni/PrintDevice.hpp.gcc31 Fri Nov 16 21:23:43 2001
+++ Omni/PrintDevice.hpp Tue Jan 22 14:16:30 2002
@@ -140,6 +140,7 @@
ostream *outputStream_d;
streambuf *outputStreamBuf_d;
+ FILE *outputStreamFILE_d;
int fShouldDeleteOutputStream_d;
char *pszDriverName_d;
char *pszDeviceName_d;
|
|
From: Tim W. <tw...@re...> - 2002-01-22 12:13:51
|
I have been trying to compile Omni using the GCC 3.1 RPM packages from Red Hat Rawhide, and have made a patch that makes it go. I have tried to keep the changes minimal. They are largely to do with explicitly declaring that we want to use the 'std' namespace by default, although there are some other issues as well: o cerr can't be the LHS of an assignment o filebuf(int&) constructor no longer exists o some missing includes o unsigned char* vs char* Is this list the right place to send a patch to? Tim. */ |
|
From: Michael S. <mi...@ea...> - 2002-01-10 21:27:46
|
On Thursday 10 January 2002 03:27 pm, Pete Zannucci wrote: > ... > The point here was to explain that you don't need the caching > mechanisms in place for having non-current information about the > printer at a particular time. Only when the printer can't return > real-time information (in the middle of processing data) will the > query information of the device need to be pulled from a cache. > At that point in time, everything will work the same between a > multi-user printer and a single user. There isn't any difference > except to make sure both cases can be handled in the same fashion. Without caching you are going to run very, very slowly with multiple users/processes asking for printer status. Also, state information queries can be very time consuming on some printers, due to the interface, amount of information, or protocol(s) being used. Also, many printers offer a "continuous update" mode that a driver can use to get status/configuration updates *when they happen*, instead of polling all the time. This further improves performance because the monitor only updates the status/config info as needed, rather than rebuilding that data at regular intervals, on-demand, or both. *My* point is that you *do* need a caching mechanism in place; it may not be used all the time, but it *will* be used. > I would also state with most printers, you still will only have one > process at a time accessing them so the item about multiple windows > should go away. The spool system should be the process of choice > because with most printers, you can't print to them from multiple Repeat after me: "Applications do not directly communicate with the printer device." Applications (and even the spooler, if you make the device monitor a separate daemon) communicate with an intermediary which manages access to the printer device. In the normal course of events, you may have several (or thousands) of processes/users requesting the current status of the printer. This is one of the reasons that a certain very popular Windows file/printer sharing program (SAMBA) has to cache all of the printer and job status information to keep up. Under UNIX/Linux today, few applications actually know enough to communicate with the printing system to keep track of the current printer and job information. In the future, thanks to GNOME and KDE, many more applications will be "printer-aware" and will be asking for things like "what is your current status", or "what is the status of the job I just printed for this user?". What does this mean? Well, for one thing we need to cache the state information. We also need to integrate state/configuration reporting with the printing system, so that applications have a single interface for printing. This interface will likely be abstracted to support multiple printing environments (e.g. KDEprint). > ... > This was to bring up a point that a separate process could track that > data to and from the printer. The management of that data via that > process would be beneficial because the associated code that is run > by that process will know the specifics of the datastream and when it > can query, abort, send additional info. etc. to the printer. > > If you have two printers that the protocol is the same, why re-write > the code that manages the protocol (bidirectional send, receive, > abort, restart, etc) code into each driver. The individual protocol > code that can be shared on a grouping of printers therefore written > once, tested once, and plugged in along with its sister printer > driver. Your first paragraph conflicts with the second. You can't write a general-purpose device interface (say, for IEEE-1284 packet mode) that can handle aborting a job cleanly by "managing the print data", unless you have the driver tell the device interface what each piece of data is. You might be able to define a subset of devices for which this would work, but doing it in a general way is very, very difficult. In CUPS we use pipes between the driver/filter processes and the backend (device interface) that communicates with the printer. CUPS 1.2 adds the "backchannel" pipe that allows bidirectional comm with the printer through the backend which handles the device-specific communication stuff. Both the driver/filter and backend processes can communicate information back to the scheduler which is provided to the client(s) that need it. If a job is cancelled, the printer driver is responsible for sending any required "cleanup" data to the backend - this will make sure that the current page is ejected, the printer is reset, and so forth. The point of the last paragraph is to show that it *is* possible to support device interface/backend software for multiple devices, or to substitute device interfaces, without having to change the printer driver or add special handling code to the device interface. > ... > From a printing application perspective, I would not want to have to > code IPP into it. I would expect the appropriate subsystems to > handle the management of this for me. I would expect nice query, > set, page, job, and drawing commands to be all I would worry about. > The system APIs I utilize should do all the management and how we > talk to the printer from a system perspective should be nebulous. > printer is. I believe that a lot of this is already available from the KDE and GNOME folks (for the general interface), and is provided specifically in the CUPS API for CUPS. > We are still grappling with the issues of renderer and driver > interface in these groups. The licensing issue is very real and that > is why it is a hot button for a number of people. Vendors would > rather not have to open source their intellectual property because > they have to run their drivers in the same process as open source > licensed code. Lets be honest - Ghostscript is the stumbling block, as most print files in UNIX are PostScript. Everything else is available in many forms and under many licenses, but Ghostscript is only available as GPL or AFPL. Putting a generic raster interface into Ghostscript is not new - we've been doing it since 1993 - and it works very well. The generic interface bypasses those licensing issues nicely. > IPP is typical for use with communications between systems and > systems/printers. This does not address the fact of how an > application talks to a driver or finds out information about the > capabilities of the subsystem and driver combination (fonts and other > things that can be lumped under system). What I am pointing out is > additional things that should be in place. Actually, IPP *does* address those things in several of the more recent extension proposals in the PWG. I *strongly* urge you to look at the PWG web site (http://www.pwg.org/ipp/) or talk with some of the people in IBM doing work on IPP... > What I was attempting to point out is that we need to define > interfaces for standardization and to be able to allow extension. We > shouldn't be tied to the past with things such as PPDs or munging PPDs are still the ONLY common printer description format that is available. They also have the advantage of limiting the amount of special-case stuff you need (XML for Printer Driver ABC, PPD for PostScript Printer XYZ, etc.) just to support printing. > them so that we now become incompatible with applications that might > not know how to parse the data. An API needs to be defined with data If you do it right, any compliant PPD parser will ignore the extra attributes/comments. > structures, possibly XML, to isolate the application from having to > do the tedious work such as parsing information that may need to be > changed in the future. Methods and managing should be crisply defined > for the application via an API for capabilities support. The PWG (again) has a working group developing a common XML format for printer description information, which may be adopted widely enough to be useful. That said, any successful replacement for PPD will have to support a superset of what PPD does, and allow for automated conversion from PPD to XML (and perhaps back to PPD) -- ______________________________________________________________________ Michael Sweet, Easy Software Products mi...@ea... Printing Software for UNIX http://www.easysw.com |
|
From: Pete Z. <pz...@us...> - 2002-01-10 20:28:06
|
> ...
> This all really depends on what set of problems you want to solve.
> If you look at several scenarios it will better define the
components
> that are needed and the way you could handle most of the scenarios.
> We need to handle:
> - Device configuration information dynamic from the printer
> - Status information returned from the printer
> - Local configured printer
> - Network configured printer
> I would argue that we do not want to distinguish between a local
> and network printer. All printers should be treated the same, and
> an application that communicates with a local print queue should be
> able to access a network print queue the same way. Again, I'm
> harping on network transparency!
>
> I agree with this. I would further argue that if the behavior of the
> printer differs depending upon whether it's locally connected in a
> single user environment vs. remotely connected, or in a multiuser
> environment, that the system violates the "principle of least
> surprise". Unless it's absolutely impossible to provide identical
> semantics (which I don't believe it is here), distinguishing these two
> cases will simply lead to user confusion.
The above was an example of problems to solve, not all the problems or that
each of the problems should be handled in different ways. If you don't
define what we are trying to solve we will never put code in place to
handle
those conditions. This wasn't meant to differentiate the items.
> 1. Local printer configuration and capabilities
>
> The local printing (single user) scenario is fairly easily
handled
> when utilizing IPC mechanisms. Latency and information about the
> printer go away in this scenario because you don't have to worry
> about the 100 user scenarios.
> I would argue that even a single user will have multiple windows,
> etc. open that want to access a printer at the same time,
> especially to check the current status.
>
> While it's true that the latency issue largely goes away in this case
> Epson printers do, and the driver deals with this), it's really not
> clear to me why we want to special case this.
The point here was to explain that you don't need the caching mechanisms
in place for having non-current information about the printer at a
particular
time. Only when the printer can't return real-time information (in the
middle
of processing data) will the query information of the device need to be
pulled
from a cache. At that point in time, everything will work the same between
a
multi-user printer and a single user. There isn't any difference except to
make sure both cases can be handled in the same fashion.
I would also state with most printers, you still will only have one process
at
a time accessing them so the item about multiple windows should go away.
The
spool system should be the process of choice because with most printers,
you
can't print to them from multiple apps. The application will not have
access to the output device so spooling is the only real option here to
return the application to the user when multiple apps are printing.
> Local printer status information
>
> When doing local printing, the status should be immediate and any
> device specific protocol converter (daemon) of the data be manage
> the flow to and from the printer to always maintain an accurate
> account of the status of the job and printer state.
>
> The device daemon should *not* try to understand the data to/from
the
> printer, nor should we expect it to track printer or job status.
> Specialization leads to bloat and all sorts of implementation
problems.
>
> Depends upon exactly what the device daemon does. If the device
> daemon actually talks to the printer, it may have to understand the
> data if the printer is a winprinter (the infamous Samsung laser
> printer requires reasonably correct timing for sending data). But the
> application shouldn't know about the existence of something like this,
> and certainly shouldn't talk to it.
This was to bring up a point that a separate process could track that data
to and from the printer. The management of that data via that process
would be beneficial because the associated code that is run by that process
will know the specifics of the datastream and when it can query, abort,
send additional info. etc. to the printer.
If you have two printers that the protocol is the same, why re-write
the code that manages the protocol (bidirectional send, receive, abort,
restart, etc) code into each driver. The individual protocol code
that can be shared on a grouping of printers therefore written once,
tested once, and plugged in along with its sister printer driver.
> - An IPC mechanism for getting dynamic information from the
> driver and subsystem will be mandatory for licensing purposes.
> It would likely be simpler if a singular interface could be used
> by both an application and the renderer.
> I would argue that an IPC mechanism at the application level has
> already been defined and implemented - IPP. Between driver and
> device, the interface to use is the pipe/socket: that abstracts
> the device IO into simple modules that can be reused for many
> drivers and devices. The printer-specific stuff is then handled
> entirely by the printer driver, which has to be specialized...
> I'd like to repeat my question to the people advocating a new
> mechanism: what required capabilities does IPP lack?
I don't think that we are really advocating something other than IPP. It
may end up that way but I think we are just talking about two different
levels and communications areas of the system.
From a printing application perspective, I would not want to have to code
IPP into it. I would expect the appropriate subsystems to handle the
management of this for me. I would expect nice query, set, page, job, and
drawing commands to be all I would worry about. The system APIs I utilize
should do all the management and how we talk to the printer from a system
perspective should be nebulous.
printer is.
We are still grappling with the issues of renderer and driver interface
in these groups. The licensing issue is very real and that is why it is
a hot button for a number of people. Vendors would rather not have to open
source their intellectual property because they have to run their drivers
in the same process as open source licensed code.
IPP is typical for use with communications between systems and
systems/printers. This does not address the fact of how an application
talks to a driver or finds out information about the capabilities
of the subsystem and driver combination (fonts and other things that
can be lumped under system). What I am pointing out is additional
things that should be in place.
What I was attempting to point out is that we need to define interfaces
for standardization and to be able to allow extension. We shouldn't
be tied to the past with things such as PPDs or munging them so that
we now become incompatible with applications that might not know how
to parse the data. An API needs to be defined with data structures,
possibly XML, to isolate the application from having to do the tedious
work such as parsing information that may need to be changed in the
future. Methods and managing should be crisply defined for the
application via an API for capabilities support.
Peter Zannucci
IBM Linux Technology Center
Open Source Software Development
Omni Print Project http://sourceforge.net/projects/omniprint
Austin, TX - Tel. 512-838-4687 (t/l 678) pz...@us...
|
|
From: Robert L K. <rl...@al...> - 2002-01-10 00:56:17
|
From: Michael Sweet <mi...@ea...> Date: Wed, 9 Jan 2002 09:00:26 -0500 On Tuesday 08 January 2002 05:27 pm, Pete Zannucci wrote: > ... > This all really depends on what set of problems you want to solve. > If you look at several scenarios it will better define the components > that are needed and the way you could handle most of the scenarios. > We need to handle: > - Device configuration information dynamic from the printer > - Status information returned from the printer > - Local configured printer > - Network configured printer I would argue that we do not want to distinguish between a local and network printer. All printers should be treated the same, and an application that communicates with a local print queue should be able to access a network print queue the same way. Again, I'm harping on network transparency! I agree with this. I would further argue that if the behavior of the printer differs depending upon whether it's locally connected in a single user environment vs. remotely connected, or in a multiuser environment, that the system violates the "principle of least surprise". Unless it's absolutely impossible to provide identical semantics (which I don't believe it is here), distinguishing these two cases will simply lead to user confusion. > 1. Local printer configuration and capabilities > > The local printing (single user) scenario is fairly easily handled > when utilizing IPC mechanisms. Latency and information about the > printer go away in this scenario because you don't have to worry > about the 100 user scenarios. I would argue that even a single user will have multiple windows, etc. open that want to access a printer at the same time, especially to check the current status. While it's true that the latency issue largely goes away in this case (at least if the printer supports an IEEE 1284.4 packet mode, which Epson printers do, and the driver deals with this), it's really not clear to me why we want to special case this. > Local printer status information > > When doing local printing, the status should be immediate and any > device specific protocol converter (daemon) of the data be manage > the flow to and from the printer to always maintain an accurate > account of the status of the job and printer state. The device daemon should *not* try to understand the data to/from the printer, nor should we expect it to track printer or job status. Specialization leads to bloat and all sorts of implementation problems. Depends upon exactly what the device daemon does. If the device daemon actually talks to the printer, it may have to understand the data if the printer is a winprinter (the infamous Samsung laser printer requires reasonably correct timing for sending data). But the application shouldn't know about the existence of something like this, and certainly shouldn't talk to it. > - An IPC mechanism for getting dynamic information from the > driver and subsystem will be mandatory for licensing purposes. > It would likely be simpler if a singular interface could be used > by both an application and the renderer. I would argue that an IPC mechanism at the application level has already been defined and implemented - IPP. Between driver and device, the interface to use is the pipe/socket: that abstracts the device IO into simple modules that can be reused for many drivers and devices. The printer-specific stuff is then handled entirely by the printer driver, which has to be specialized... I'd like to repeat my question to the people advocating a new mechanism: what required capabilities does IPP lack? -- 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 Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Michael S. <mi...@ea...> - 2002-01-09 13:59:45
|
On Tuesday 08 January 2002 05:27 pm, Pete Zannucci wrote: > ... > This all really depends on what set of problems you want to solve. > If you look at several scenarios it will better define the components > that are needed and the way you could handle most of the scenarios. > We need to handle: > - Device configuration information dynamic from the printer > - Status information returned from the printer > - Local configured printer > - Network configured printer I would argue that we do not want to distinguish between a local and network printer. All printers should be treated the same, and an application that communicates with a local print queue should be able to access a network print queue the same way. Again, I'm harping on network transparency! > 1. Local printer configuration and capabilities > > The local printing (single user) scenario is fairly easily handled > when utilizing IPC mechanisms. Latency and information about the > printer go away in this scenario because you don't have to worry > about the 100 user scenarios. I would argue that even a single user will have multiple windows, etc. open that want to access a printer at the same time, especially to check the current status. > Information does not necessarily need to be statically maintained > unless the printer does not handle bi-directional information > that fully describes its configuration. If the printer does not Most printers cannot "fully describe" their configuration. The smartest inkjets provide a model ID (which often is too general to be of use), installed inkset, paper status, and ink levels. That is enough if you know which driver to use, etc., but not which variety of ESC/P, PCL, etc. to use, and what capabilities the printer has. > ... > It can be done by reading a PPD or it can be done by calling a > printer driver and getting the current information back. In either > scenario, it would be a very good idea to have an API that can return > the information in a STANDARD format to a calling application. It Right, and currently the best match for that "standard" format is a PPD file, which is supported by a lot of applications and adequately describes most options. I'm not saying PPD is the best format in the world (there are many issues, and I'm quite sure that Adobe would be interested in addressing them in a new rev of the spec), but it is the best supported format, both under Linux and other operating systems. It is also already in use in all of the scenarios that have been brought up. > ... > Local printer status information > > When doing local printing, the status should be immediate and any > device specific protocol converter (daemon) of the data be manage > the flow to and from the printer to always maintain an accurate > account of the status of the job and printer state. The device daemon should *not* try to understand the data to/from the printer, nor should we expect it to track printer or job status. Specialization leads to bloat and all sorts of implementation problems. > ... > - An IPC mechanism for getting dynamic information from the driver > and subsystem will be mandatory for licensing purposes. It would > likely be simpler if a singular interface could be used by both an > application and the renderer. > ... I would argue that an IPC mechanism at the application level has already been defined and implemented - IPP. Between driver and device, the interface to use is the pipe/socket: that abstracts the device IO into simple modules that can be reused for many drivers and devices. The printer-specific stuff is then handled entirely by the printer driver, which has to be specialized... As for licensing issues, simpler public interfaces eliminate this problem - if a vendor doesn't like the license the "standard" implementation uses, it can roll its own interfaces. The TurboPrint folks do this for their CUPS drivers, for example, since they don't want to link to the CUPS imaging library (which is GPL'd, while the rest of the CUPS API is LGPL'd...) to read the raster data. Instead, they rolled their own read-header/pixels code. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mi...@ea... Printing Software for UNIX http://www.easysw.com |
|
From: Robert L K. <rl...@al...> - 2002-01-09 01:26:23
|
From: Ben Woodard <be...@zo...> Date: Mon, 07 Jan 2002 15:44:42 -0800 > PostScript, with all its weaknesses, is still the defacto standard > printing format for UNIX apps. Any printing solution will have to > support it to be accepted, which is why CUPS includes a version > of GNU Ghostscript for non-PS printers, and why we use PPDs. What ever happend PDF 1.4. How many applications generate PDF 1.4? How many applications generate PostScript? -- 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 Gimp Print/stp -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Pete Z. <pz...@us...> - 2002-01-08 22:27:31
|
>> > Ultimately, you *really* want a static snapshot of what a driver
>> > can
>>
>> I think that this is a bit of an implementation thing. I really don't
>> want a static representation.
>>
>> > do. This ideally should be a data file that can be read by a
>> > driver/ filter (using a standard API of course) to handle any
>> > printer/job specific setup. For devices whose options depend on,
>> > say, what kind of ink cartridge is installed, a background driver
>> > process can monitor the printer and update the static snapshot as
>> > needed (and obviously any driver would need to reject/stop a job
>> > that won't print on the current configuration)
>>
>> I'm really not a fan of this functionality. I'd much rather have some
>> sort IPC mechanism rather than some sort of dropbox.
>
> The problem with IPC is that it can cause major performance problems,
> especially if you have to wait for a driver program to try to
> communicate with a printer, which may be servicing a request from
> another process/system which also wants to print... Also, any IPC
> mechanism you come up with has to be supported over networks to be
> useful - network transparency is a requirement in today's "connected"
> world...
>
> No matter how you do it, your application will only have a static
> snapshot from when it queried the printer driver. Rebuilding this
> snapshot each time it is requested is inefficient and will lead to
> major performance and availability issues.
This all really depends on what set of problems you want to solve.
If you look at several scenarios it will better define the components
that are needed and the way you could handle most of the scenarios.
We need to handle:
- Device configuration information dynamic from the printer
- Status information returned from the printer
- Local configured printer
- Network configured printer
1. Local printer configuration and capabilities
The local printing (single user) scenario is fairly easily handled
when utilizing IPC mechanisms. Latency and information about the
printer go away in this scenario because you don't have to worry
about the 100 user scenarios.
Information does not necessarily need to be statically maintained
unless the printer does not handle bi-directional information
that fully describes its configuration. If the printer does not
handle everything, then it should be up to some API interface into
the print subsystem to be able to provide a representation of the
configuration back to the application. Notice I said interface and
is required no matter where the information is coming from.
The Print Summit was about interfaces and how do we get at the info.
that is needed so that there can be consistency as the print system
in Linux does its necessary evolution.
It can be done by reading a PPD or it can be done by calling a printer
driver and getting the current information back. In either scenario,
it would be a very good idea to have an API that can return the
information in a STANDARD format to a calling application. It would
be of benefit if any information that may need to be extended, such
as driver information, be abstracted away to an API that will allow
for a standard format of information to be passed back so that as
things evolve the APIs should be consistent from an application
perspective.
Local printer status information
When doing local printing, the status should be immediate and any
device specific protocol converter (daemon) of the data be manage
the flow to and from the printer to always maintain an accurate
account of the status of the job and printer state.
2. Networked printer configuration and capabilities
In a networked environment with multiple users the problem gets
a little harder. It now depends on the components and how you
manage the components but you are going to have to rely more on
a static representation of the printer than a dynamic one.
Again, if you have some protocol conversion daemon that is managing
the data going back and forth between the printer and the system,
it will know the current state of the printer and if it will have to
rely on a statically cached version of the configuration or it can
actually request an update from the printer.
Networked printer status
This one will work very similar in that if the converter is managing
the flow of data and it understands the state of the printer, it can
make the decision on if it can query the printer or it has to pass
back to a caller (spooler or gui app) a static cache of the last known
state of the printer.
The static cache is necessary to avoid latency in the information.
The conversion code should be able to know the type of the printer and
when a transaction can occur with the printer.
Again, there should be:
- Common API interfaces for getting the information to the application
- Standard data format that is returned to the application looking for
capabilities
Underlying code and implementation does not need to be exposed as long
as there is a defined API for getting the data in a standard format.
- Tightly coupled component with the printer driver to manage the data
flow to and from the printer and allow for things like getting caps.
information from the printer, getting status from the printer,
restarting pages and/or jobs, and aborting jobs.
- An IPC mechanism for getting dynamic information from the driver and
subsystem will be mandatory for licensing purposes. It would likely
be simpler if a singular interface could be used by both an application
and the renderer.
** This of course doesn't include multiple systems hitting one printer or
a networked environment where the printers are on different networks.
We went round and round a number of times on implementations and for
capabilities once we did the preliminary work for the summit, it really
got down to standardizing a way for the application to get the information
about the device and a way the driver gets told the settings when the job's
data is to be generated.
Fonts and drawing caps. are a different issue and purely dependant on the
rendering system and printer driver combo.
Peter Zannucci
IBM Linux Technology Center
Open Source Software Development
Omni Print Project http://sourceforge.net/projects/omniprint
Austin, TX - Tel. 512-838-4687 (t/l 678) pz...@us...
|
|
From: Michael S. <mi...@ea...> - 2002-01-08 13:56:56
|
On Monday 07 January 2002 06:44 pm, Ben Woodard wrote:
> > Ultimately, you *really* want a static snapshot of what a driver
> > can
>
> I think that this is a bit of an implementation thing. I really don't
> want a static representation.
>
> > do. This ideally should be a data file that can be read by a
> > driver/ filter (using a standard API of course) to handle any
> > printer/job specific setup. For devices whose options depend on,
> > say, what kind of ink cartridge is installed, a background driver
> > process can monitor the printer and update the static snapshot as
> > needed (and obviously any driver would need to reject/stop a job
> > that won't print on the current configuration)
>
> I'm really not a fan of this functionality. I'd much rather have some
> sort IPC mechanism rather than some sort of dropbox.
The problem with IPC is that it can cause major performance problems,
especially if you have to wait for a driver program to try to
communicate with a printer, which may be servicing a request from
another process/system which also wants to print... Also, any IPC
mechanism you come up with has to be supported over networks to be
useful - network transparency is a requirement in today's "connected"
world...
No matter how you do it, your application will only have a static
snapshot from when it queried the printer driver. Rebuilding this
snapshot each time it is requested is inefficient and will lead to
major performance and availability issues.
> > Also, trying to get printer drivers and applications to talk to
> > each other directly is a mistake. It doesn't scale. Better to
>
> I personally think this is completely wrong. I don't see how it
> doesn't scale at all.
Ben, I've been doing this stuff for a *long* time. Sketch a quick
design for an API that allows multiple applications (possibly from
remote systems) to communicate with a driver directly, which then
talks directly to the printing device.
The bottleneck quickly becomes the printer and driver, which must
multiplex status inquiries from multiple sources, and also somehow
keep printing. The only way to support such a scenario is to keep
an internal snapshot of the printer state and feed that to the
"clients" when they ask for it. Guess what, you have a *static*
representation of the printer, but rather than storing that
representation someplace that can be quickly forwarded to the
client, you are re-processing everything. On many printers this
can mean handling a *lot* of information (hundreds of media sizes
and types, not including resolution, quality, color, etc. modes)
for no real benefit. If you do create a static snapshot that
is quickly sent to the client, then you have *exactly* the
mechanism provided by CUPS...
> > have the driver maintain a snapshot of the current configuration
> > than to introduce potentially long round-trip times which may
> > require UI intervention ("your printer is not connected or turned
> > off") or have to be postponed because the device is busy.
>
> I'm not a fan of this dropbox methodology that he is advocating. I
> agree that there is a problem if the printer or the printer is turned
> off we need to be able to provide the user with information in a
> timely manner but I still think that it needs to be provided by the
> drivers.
1. Printer configurations change infrequently.
2. Most conflicts between options can be stored statically; that is,
duplex printing is *always* incompatible with transparency
media, unless someone comes up with one-way ink :) Those
that depend on a hardware feature (which type of ink cartridge
is installed) can still be expressed statically, but depend
on some dynamic info that the driver needs to update as
needed.
3. You *must* design for the 100 (or more) people trying to
monitor/print to a printer. See previous description of the
problem.
4. There is a big difference between printer capababilities (that
are provided to the user as a list of options) and printer
state. If tray 4 is empty, does that mean that a user can't
print to tray 4? Probably not. Printer caps and state should
be treated separately.
> ...
> > PostScript, with all its weaknesses, is still the defacto standard
> > printing format for UNIX apps. Any printing solution will have to
> > support it to be accepted, which is why CUPS includes a version
> > of GNU Ghostscript for non-PS printers, and why we use PPDs.
>
> What ever happend PDF 1.4.
There are still a lot of problems with PDF in real-world printing. It
works great if you want a document printed all on the same media,
with the same options, but it still doesn't support the full range
of printer options that PostScript does. Basically, all you get (if
you have a compatible app, and Acrobat Reader doesn't even do this)
are a series of job ticket attributes that can be applied globally
or to individual pages, and unfortunately these attributes don't
support anything as simple as media type, etc. See Adobe technote
5620, Portable Job Ticket Format.
> ...
> > The printer driver is not the right place for this; the printing
> > system needs to manage fonts, and provide an API for drivers to
> > register/retrieve them.
>
> Once again I think Michael and I differ here. I think that fonts
> should be part of the comabilities subsystem but I wasn't pushing
> that yet.
Both Microsoft and Apple put the font handling in the API, not in
the driver. Drivers are free to support some fonts directly, however
all an app sees is a common set of fonts that are available. If
a printer vendor provides a set of its own fonts, it must also
include display fonts so they are available to the system as a
whole.
Then it simply becomes a matter for the app to choose a font it
wishes to use; if the printer doesn't have that font, the driver
can either download the font (PCL/PS drivers do this in the
Windows world) or rasterize it at the printer's resolution.
Not surprisingly, this is the functionality that GNOME provides,
and KDE to a much lesser extent. CUPS 1.2 will understand all of
the "required resource" stuff included with a PS file; when a
file uses a font called "Foo-Roman", the CUPS filter can look in
the PPD file to determine if the printer has that font, and if not
embed the font automatically. CUPS already does this when printing
text files...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mi...@ea...
Printing Software for UNIX http://www.easysw.com
|
|
From: Ben W. <be...@zo...> - 2002-01-08 11:25:45
|
> Ultimately, you *really* want a static snapshot of what a driver can
I think that this is a bit of an implementation thing. I really don't
want a static representation.
> do. This ideally should be a data file that can be read by a driver/
> filter (using a standard API of course) to handle any printer/job
> specific setup. For devices whose options depend on, say, what kind
> of ink cartridge is installed, a background driver process can monitor
> the printer and update the static snapshot as needed (and obviously
> any driver would need to reject/stop a job that won't print on the
> current configuration)
I'm really not a fan of this functionality. I'd much rather have some
sort IPC mechanism rather than some sort of dropbox.
<snip>
> Also, trying to get printer drivers and applications to talk to
> each other directly is a mistake. It doesn't scale. Better to
I personally think this is completely wrong. I don't see how it
doesn't scale at all.
> have the driver maintain a snapshot of the current configuration
> than to introduce potentially long round-trip times which may
> require UI intervention ("your printer is not connected or turned
> off") or have to be postponed because the device is busy.
>
I'm not a fan of this dropbox methodology that he is advocating. I
agree that there is a problem if the printer or the printer is turned
off we need to be able to provide the user with information in a
timely manner but I still think that it needs to be provided by the
drivers.
> > ...
> > A GUI application will need to query the printer driver for its
> > strings as well as hints as to how to display the information.
>
> Again, a *static* file makes this a lot easier. I'm not 100%
> happy that the PPD spec only allows a single language right now,
> but others have suggested a common translation catalog that covers
> common options...
>
> > ...
> > While inkjets may not need acceleration, there are other printers
> > that do. It is much more efficient to transfer a high level call like
> > drawing a rounded box than it is to transfer a bitmap image of that
> > box. Some examples of high level languages are: HP-GL/2, PCL6, and
> > even Postscript. Should there be two different code paths for
> > printing to an inkjet printer vs printing to a Postscript printer?
>
> HP-GL/2 is a waste of time. There are too many special cases and
> too many differences in appearance between models (even within HP
> models).
>
> PCL 6 is an option, but can be handled by existing software like
> Ghostscript without requiring the application to know about it.
>
> PostScript, with all its weaknesses, is still the defacto standard
> printing format for UNIX apps. Any printing solution will have to
> support it to be accepted, which is why CUPS includes a version
> of GNU Ghostscript for non-PS printers, and why we use PPDs.
>
What ever happend PDF 1.4.
> > ...
> > One example of reducing data that is sent to the printer driver is to
> > use device fonts that are resident in the printer. To achieve
> > WYSIWYG printing,
> > an application will have to query the printer driver for its font
> > metrics.
>
> The printer driver is not the right place for this; the printing
> system needs to manage fonts, and provide an API for drivers to
> register/retrieve them.
Once again I think Michael and I differ here. I think that fonts
should be part of the comabilities subsystem but I wasn't pushing that
yet.
-ben
>
> > ...
> > something that the operating system should store and tell the
> > application and printer driver.
>
> The application should no nothing about what driver is being used,
> just what capabilities the printer has...
>
> --
> ______________________________________________________________________
> Michael Sweet, Easy Software Products mi...@ea...
> Printing Software for UNIX http://www.easysw.com
>
> _______________________________________________
> printing-cap mailing list
> pri...@fr...
> http://freestandards.org/mailman/listinfo/printing-cap
|
|
From: Michael S. <mi...@ea...> - 2001-12-28 17:22:00
|
On Friday 28 December 2001 11:01 am, Robert L Krawitz wrote: > ... > That would probably work, although applications would need to reread > the PPD whenever they wanted to start a new print job. I think this would be the case, even for a dynamic data interface. > For that > matter, so would CUPS. Yes, but the device daemons that are being used do this by telling CUPS to use the new PPD file (i.e. CUPS only re-reads the file as needed) > ... > Well, for CUPS-based drivers at least it will work, and other apps > will "see" the standard PPD file that will still work everywhere. > > I'm nervous about what this leads to. If CUPS has one set of > extensions, another IPP-based system has another, and so forth, we > get into trouble fast. Not to "toot our own horn" too much, but right now CUPS is the only IPP implementation that actually deals with printer drivers, options, etc. at this level. MS IPP and Novell IPP both still deal just with sending raw print data... :( Also, CUPS is already extending IPP by providing PPD files, drivers, etc. on top of IPP (documented and registered, of course, with the PWG), and anything we do to support printer drivers on top of IPP will be an extension... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mi...@ea... Printing Software for UNIX http://www.easysw.com |
284 messages has been excluded from this view by a project administrator.
