But the NSFont is opaque and
mostly implemented in the gui. It delegates some of its functionality to
the backend via GSFontInfo, but ghostscript provides a higher level
implementation thus it is not a good match for the gslib backend. I see
two ways to circumvent this: one is to put a gs_font in GSFontInfo and
try
to synchronise it to NSFont but this is error prone, the other is to
subclass NSFont in the backend and reimplement it using ghostscript, but
the superclass still had wrong implementations which the gui might try
to
use. The solution seems to be to remove all implementations of graphics
related things from the gui and do them in the backend.