Re: [RFR] templates://tgif/{tgif.templates}
Carlo Segre wrote:
> Justin B Rye wrote:
>> This all looks fair enough. Maybe you could say "Please select",
>> but if it was really being polite and considerate you'd think it
>> would just consult LC_PAPER and LC_MEASUREMENT for its defaults and
>> not bother the user with questions...
>
> I think there might be value in allowing the user to select a measurement
> which differs from the locale. As a scientist, I prefer working in
> metric on my drawings even though I live in en_US.utf8 locale. For the
> papersize, I could see making the selection based on LC_PAPER once I
> figure out how to do it...
If you want to use US spellings and US dollars but prefer metric
units, set LC_MEASUREMENT. If you insist on using centimetres for
some apps (such as OpenOffice and The GIMP) and inches in others
(such as Emacs and Tgif), it seems to me you'd be prepared to edit
the config-files appropriately. After all, none of those others ask
questions like this on install, do they?
>> Wikipedia makes some usefully complementary points at
>> "http://en.wikipedia.org/wiki/Tgif_(program)", though its claim that
>> Tgif is unusual in using a grid makes no sense to me.
>>
>> Is it worth mentioning the use of Prolog?
>
> I just read the Wikipedia entry and it is probably a bit out of date too.
> here is my suggestion for additions to the long description (I never
> really liked the old one myself). This is description extracted from the
> man page. The last paragraph mentions the file format and Prolog.
> Perhaps it is overkill?
>
> Tgif (originally the "Tangram Graphic Interface Facility") is a
> classic drawing program for 2D vector graphics which supports
> hierarchical construction of drawings and easy navigation between
> sets of drawings.
"Hierarchical construction" doesn't really convey whatever it was
they were hoping to tell me. I suppose it's talking about the way
(following what's now standard operating procedure for vector
editors) it works by creating hierarchically grouped "objects". But
are the "sets of drawings" all on one grid, or in separate .obj
files, or what? And what less easy navigation mechanism do its
competitors use?
> Tgif natively produces PostScript output suitable for LaTeX (PS and
> EPS), X11 bitmap, and X11 pixmap files. Other vector formats (SVG and
> PDF) as well as raster file formats (JPEG, PNG, and GIF) can be
> created with the use of standard filters.
A bit wordy, but otherwise good.
> Primitive objects supported by tgif are rectangles, ovals,
> rounded-corner rectangles, arcs, polylines, polygons, open-splines,
> closed-splines, and text (please note that the splines tgif draws
> are not Bezier curves). Objects can be grouped together to form a
> grouped object. A primitive or a grouped object can be made into an
> icon object or a symbol object through user commands.
(s/Bezier/Bézier/, "s/ / /g")
This is definitely getting too long-winded; a lot of this is now
routinely expected from a vector editor...
Maybe just boil the first three paragraphs down to:
Tgif (originally the "Tangram Graphic Interface Facility") is a
classic drawing program for 2D vector graphics. Image objects
can be hierarchically constructed out of primitives such as
polygons, text, and splines (though the splines Tgif draws are
not Bézier curves).
.
Tgif natively supports PostScript formats suitable for LaTeX, and
basic X11 bitmap/pixmap formats. Other vector and raster image
formats such as SVG and PNG can be handled via filters.
> X11 bitmap files, X11 pixmap files (version 1.0 only) and
> Encapsulated PostScript (EPS) files can be imported into tgif and be
> represented as tgif primitive objects. Files in other raster formats
> (e.g, JPEG, TIFF, etc.) can also be imported through the use of
> external tools which convert them into X11 pixmap files.
Or to summarise, "and the same goes for importing". So if we just
make sure we use vague terms like "handle" instead of "export" the
first time round we can drop this whole paragraph.
Except maybe it should state more clearly that its .xpm *output*
format is also (presumably) a stupendously obsolete version?
> Tgif stores drawings as a list of objects in a text file with a
> .obj extension and individual building block objects in a symbol
> file with a .sym extension. Both types of files are stored in the
> form of Prolog facts. Prolog code can be written to interpret the
> drawings.
Summarising:
.
Tgif stores drawings as .obj files and individual building-block
objects as .sym files, both in Prolog-compatible factfile format.
But if this is anything more than an amusing quirk, shouldn't tgif
suggest gprolog or something?
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: