From: Mari Voipio <mari.voipio@iki.fi>
Subject: Re: Figure formats
Date: Tue, 26 Apr 2005 16:43:41 +0300 [thread overview]
Message-ID: <426E458D.1060005@iki.fi> (raw)
In-Reply-To: <1e17824d02cd0109ad521b4f1841dedf@unibas.ch>
Jörg Hagmann wrote:
> If you have the choice of format when preparing the figures for a book
> written with ConTeXt, what would you opt for? (The figures are being
> drawn with ChemDraw and Illustrator).
I'm not terribly good at this (yet?), but one my main guidelines in this
kind of situations in and out of ConTeXt is to keep vector graphics in
vector format and only use bitmap graphics (like png or jpg) if the
original is in a bitmap format (like a photo).
I handle mostly graphics that originate from a 3D CAD program and
different types of graphics I draw myself in CorelDraw (equivalent to
Adobe Illustrator as far as I know). These both generally produce vector
drawings The drawings from the 3D program are mostly in pdf format when
they arrive to me and I've found, somewhat to my surprise, that the best
way of handling them seems to be to include them as pdf, just to crop
them to the picture itself. I also turn my CorelDraw pics into pdf
before adding them to ConTeXt based text, that inserts them nicely and
makes it easy for me to share any graphics at request (I'm occasionally
asked to send just graphic 3.1 from manual x, so it is a good thing to
have all of them as pdf).
The nice thing with vector graphics is that they are almost indefinitely
scalable, so the size of the original is not so critical - and the files
don't take much space even when the original is bigger than the graphic
in my book.
Whenever I have to do something with bitmaps, I try to scale them close
to the final size with good graphics programs, I feel that this give me
better control over what happens to the graphics when resized (the
resolution of some of the originals is pretty bad...). On the other
hand, if it doesn't look bad in the final product, why bother...
Greetings from Finland,
Mari
PS. Here's a manual [all public] I've done by using text in ConTeXt and
vector graphics in pdf and bitmaps in jpg/png:
<http://www.kpatents.com/1Library/manuals_pr-23.htm>. For example
chapter 5 (at
<http://www.kpatents.com/1Library/manuals/pr-23/pr-23_05.pdf>) has
mainly screen capture bitmaps (I used png format) and chapter 4 (at
<http://www.kpatents.com/1Library/manuals/pr-23/pr-23_04.pdf> includes a
ton of drawings originating from our 3D CAD.
next prev parent reply other threads:[~2005-04-26 13:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-26 13:15 Jörg Hagmann
2005-04-26 13:25 ` Hans Hagen
2005-04-26 13:43 ` Mari Voipio [this message]
2005-04-26 14:03 ` Ville Voipio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=426E458D.1060005@iki.fi \
--to=mari.voipio@iki.fi \
--cc=ntg-context@ntg.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).