[Gnome-print] Re: Device independent string output
- From: Liam Quin <liam holoweb net>
- To: gnome-devel-list gnome org
- Cc: njh nudibranch csse monash edu au, gnome-print helixcode com
- Subject: [Gnome-print] Re: Device independent string output
- Date: Fri, 23 Jun 2000 07:26:56 -0400
On Thu, Jun 22, 2000 at 10:49:26AM -0400, Owen Taylor wrote:
[...]
> - There is quite a bit of code in Pango that manipulates glyphstrings.
> The most specific examples would be the routines that map from
> screen position <=> character position.
I've been thinking hard about ways to avod doing this in glayout,
if I ever get that far :-), mostly because I'd rather avoid the
memory overhead and the pain of keeping glyph strings up to date.
But I don't think I can avoid them, so I will probably hide them
under an interface that lets me cache them instead of keeping them all.
For western type, I want to us a model that has a single virtual font
with attribtes such as "small caps" and "superscript", I think.
Then glyphs from an Adobe Expert Set font can be intermixed with
the corresponding "Adobe StandardEncoding" font, possibly reencoded
to get at the extra glyphs that aren't accessible by default.
As a result, I'll probably need something like a line-of-text
structure, with interleaved text, motion and attrinute changes.
I can build that on top of a lower-level font library, as long
as I can get at pixel boundaries of glyphs for selection purposes.
But I need to know which input character(s) corresponds to which
glyph(s) if I am going to allow on-screen editing.
> - Your language will lock Pango to a specific font technology. There
> is no way such a language could support both, say, OpenType and
> Quickdraw GX fonts.
That would be a problem -- I want to start with Type 1 fonts, since
they are used in the graphic design industry. On the other hand,
Type 1 fonts can be contained inside OpenType wrappers, so it might
be OK to approach them that way if it's not too slow.
Troff has always used an internal "little language" very like what
Lauris proposes, and it can work well. SoftQuad's troff optimised
the language a lot, and also made an ascii representation that was
easy to process with awk, and was *wonderful* for testing. But
SoftQuad's was at the character level, not the glyph level, and
all of the glyph stuff was done by a separate library. If you are
interested, I'll see if I can free up the documentation for that
language and the associated library, although I'm not suggesting
using it directly. Many older typesetting machines worked in this
way too, of course.
I will also try and draw some pictures of the sorts of data
structures I might use, but I haven't been able to get my laptop
working in the hotel, so it might not be until I get back on 2nd July.
Lee
--
Liam Quin - Barefoot in Toronto - liam@holoweb.net - http://www.holoweb.net/
Ankh on irc.sorcery.net http://valinor.sorcery.net/
Co-author, The XML Specification Guide, Wiley, 1999
Forthcoming: The Open Source XML Database Toolkit
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]