Am 28.02.2010 12:55, manolo gouy wrote: >> >> After fixing a couple of minor compilation problems, I can now print >> successfully on Windows, but there's a small problem with PS output on >> Linux: I had to change >> >> %%BeginFeature: *PageSize >> -A4 >> +%% A4 >> %%EndFeature >> >> in the prolog, because PS interpretation showed an error message >> otherwise: "Error: /undefined in A4". I didn't fix this in the source, >> though. > OK, I'm not on firm ground here.
Neither am I. > I'll see if this new way runs on all > 3 platforms. What I did was just to make "A4" a comment, and that's supposed to "run" on all platforms. The question is about functionality. What is it supposed to _do_, and what does it now? I understand that it's supposed to set the paper format, but I don't know what would be the right way to do it. Maybe someone else can help, or the fltk 1.2 code (or PS output) can help. If nothing can be done now, then let's comment it out (by %%) and see later... >> Did this fix the Windows compilation problems that you mentioned? > I had several MSWin warnings about virtual classes having non virtual > constructors that I did not understand, and needed your help to > repair that. But if you don't have these warnings, let's just forget > that. Yes, I also had the warnings, and I fixed them for my Cygwin/gcc build by making ~Fl_PSfile_Device() [or something similar] virtual. I asked you if it fixed it for you because you didn't specifiy what your warnings were. I committed the changes, so if they went away for you as well... > About the class hierarchy: > I reasoned from the user viewpoint who wants the statement > Fl_Printer myprinter; > to run and create an adequate printer on all 3 platforms, > and also wants > Fl_PSfile_Device to run and create a .ps file on all 3 platforms. > The hierarchy below is the solution I found for that. But if there's > a better one, I would be happy to accept it. > Also I'm not very happy of the name Fl_Virtual_Printer. May be > Fl_Abstract_Printer would be better. > > Fl_Virtual_Printer > Fl_Quartz_Printer (on Mac) > Fl_Printer (on Mac) > Fl_GDI_Printer (on MSWin) > Fl_Printer (on MSWin) > Fl_PSfile_Device (all platforms) > Fl_PS_Printer (on X11) > Fl_Printer (on X11) Let's postpone this discussion until we know more about functionality. It was just an idea that was inspired by the Fl_Image class hierarchy, where the base class has the "simple" name and can be used as a handle for all derived classes to call the virtual methods, but that's more academically, I guess. If all works well, then we can do redesign and renaming (or leave it as it is). Maybe someone else has better ideas about the naming. The main "problem" I'm seeing now is to be able to merge both branches if we decide to do so (and I hope we will). I'm going to merge the main branch to our development branch to see how far we are away already, and to prepare the merge-back. [But, if anybody is afraid now: I'm not going to do this until there is consensus.] Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
