How to convert (unicode) text to image?

[kj]

Hi! Does anyone know of an easy way to convert a Unicode string into an image file (either jpg or png)?

TIA!

~k

 

[Benjamin Kaplan]

Hi!  Does anyone know of an easy way to convert a Unicode string into an image file (either jpg or png)?

Do you mean you have some text and you want an image containing that
text? PIL's ImageDraw module can do that.

 

[Dave Angel]

Hi! Does anyone know of an easy way to convert a Unicode string into an image file (either jpg or png)?

TIA!

~k

The question has no meaning as presently worded.

If you have Unicode text that you need to render, so that you end up
with an image of the text, as printed in some particular font and style,
you'd probably start with PIL. Or perhaps one of the gui packages, like
tkinter, wxpython, etc.

If you have Unicode that was produced by trying to decode some jpeg
image, then back up and don't do that. See the recent thread called
"Writing byte stream as jpeg format to disk". The OP there had run a
unicode decode on a byte stream that represented a jpeg file, and then
tried to encode it again to get the jpeg data. Bad idea.

If you have Unicode that specifies a file path that refers to a jpeg
file, then you need to open the file, in "rb" mode, and copy it.

If you have Unicode that gives the name of a person, and you want a
portrait of that person, you need to call a photographer() function.


The last one was a weak attempt at humor.

DaveA

 

[kj]

n image file (either jpg or png)?

Do you mean you have some text and you want an image containing that
text? PIL's ImageDraw module can do that.

Thanks for the pointer, but...

<RANT>
The documentation I have found for PIL (at
http://www.pythonware.com/library/pil/handbook) is beyond atrocious.
If this is the only way to learn how to use this library, then I
really don't understand how anyone who is not clairvoyant can do it.

Example: I went to the docs page for ImageDraw. There I find that
the constructor for an ImageDraw.Draw object takes an argument,
but *what* this argument should be (integer? object? string?) is
left entirely undefined. From the examples given I *guessed* that
it was an object of class Image, so I repeated the exercise: I
consulted the docs for the Image module. There I learn that the
constructor for the Image class takes among its parameters one
called "mode" and one called "color", but, here again, what these
parameters are is left completely undefined. ("mode" is left both
syntactically and semantically undefined; "color" is left syntactically
undefined, though the documentation includes a bit by way of semantic
definition of this parameter.)

What's up with this practice of leaving parameters undefined like
this??? Wasn't it obvious to the person writing the Image module
docs that without explaining what these parameters should be the
documentation is nearly useless? Is such poor documentation an
unintended consequence of "duck typing"???

Sorry for the outburst, but unfortunately, PIL is not alone in
this. Python is awash in poor documentation.

The number two complaint I've heard from those who dislike Python
is the poor quality of its documentation, and in particular the
fact that function parameters are typically left undefined, as is
the case in the PIL docs. I like Python a lot, but I have to agree
with this criticism. (The number one complaint has to do with the
syntactic significance of whitespace; of course, I find *this*
criticism silly.)

What is most frustrating about such poor documentation is that it
is exactly the opposite from what one would expect from the
carefulness and thoroughness found in the PEPs...

I have been using Python as my primary scripting language for about
one year, after many years of programming in Perl, and now Python
is my language of choice. But I must say that the documentation
standards I found in the Perl world are *well above* those in the
Python world. This is not to say that Perl documentation is always
excellent; it certainly has its gaps, as one would expect from
volunteer-contributed software. But I don't recall being frustrated
by Perl module docs anywhere nearly as often as I am by Python
module docs. I have to conclude that the problem with Python docs
is somehow "systemic"...

</RANT>

 

[Arnaud Delobelle]

Thanks for the pointer, but...

<RANT>
The documentation I have found for PIL (at
http://www.pythonware.com/library/pil/handbook) is beyond atrocious.
If this is the only way to learn how to use this library, then I
really don't understand how anyone who is not clairvoyant can do it.

Example: I went to the docs page for ImageDraw. There I find that
the constructor for an ImageDraw.Draw object takes an argument,
but *what* this argument should be (integer? object? string?) is
left entirely undefined. From the examples given I *guessed* that
it was an object of class Image, so I repeated the exercise: I
consulted the docs for the Image module. There I learn that the
constructor for the Image class takes among its parameters one
called "mode" and one called "color", but, here again, what these
parameters are is left completely undefined. ("mode" is left both
syntactically and semantically undefined; "color" is left syntactically
undefined, though the documentation includes a bit by way of semantic
definition of this parameter.)

The first time you read the PIL docs, read the introduction. After that
I find the docs pretty easy to use, even though it is true that it is
quite terse.

E.g. for the mode, look at the "concepts" page in the intro:

http://www.pythonware.com/library/pil/handbook/concepts.htm

What's up with this practice of leaving parameters undefined like
this??? Wasn't it obvious to the person writing the Image module
docs that without explaining what these parameters should be the
documentation is nearly useless? Is such poor documentation an
unintended consequence of "duck typing"???

Sorry for the outburst, but unfortunately, PIL is not alone in
this. Python is awash in poor documentation.

The number two complaint I've heard from those who dislike Python
is the poor quality of its documentation, and in particular the
fact that function parameters are typically left undefined, as is
the case in the PIL docs. I like Python a lot, but I have to agree
with this criticism. (The number one complaint has to do with the
syntactic significance of whitespace; of course, I find *this*
criticism silly.)

What is most frustrating about such poor documentation is that it
is exactly the opposite from what one would expect from the
carefulness and thoroughness found in the PEPs...

I find the Python docs very good on the whole.

I have been using Python as my primary scripting language for about
one year, after many years of programming in Perl, and now Python
is my language of choice. But I must say that the documentation
standards I found in the Perl world are *well above* those in the
Python world. This is not to say that Perl documentation is always
excellent; it certainly has its gaps, as one would expect from
volunteer-contributed software. But I don't recall being frustrated
by Perl module docs anywhere nearly as often as I am by Python
module docs. I have to conclude that the problem with Python docs
is somehow "systemic"...

I have never programmed in Perl (although I have needed to read some
Perl) but over the years I have used C, C++, lisp variants, PHP, Ruby, Caml
variants, Haskell, Javascript (and others before the era of the
web). I don't find that Python online docs on the web are worse than
online docs for any of those languages.

 

[alex23]

Example: I went to the docs page for ImageDraw.  There I find that
the constructor for an ImageDraw.Draw object takes an argument,
but *what* this argument should be (integer? object? string?) is
left entirely undefined.  From the examples given I *guessed* that
it was an object of class Image[...]

The docs say:

Draw(image) => Draw instance
Creates an object that can be used to draw in the given image.

It seems pretty obvious that the first argument is an 'image' to me,
and when the lib itself defines an Image class...

You "guessed" this was the case from this prominent example at the top
of the page?

import Image, ImageDraw

im = Image.open("lena.pgm")
draw = ImageDraw.Draw(im)

How much more clear can this be made?

Sorry for the outburst, but unfortunately, PIL is not alone in
this.  Python is awash in poor documentation. [...]
I have to conclude that the problem with Python docs
is somehow "systemic"...

Yes, if everyone else disagrees with you, the problem is obviously
"systemic".

What helps are concrete suggestions to the package maintainers about
how these improvements could be made, rather than huge sprawling
attacks on the state of Python documentation (and trying to tie it
into the state of Python itself) as a whole. Instead, what we get are
huge pointless rants like yours whenever someone finds that something
isn't spelled out for them in exactly the way that they want.

These people are _volunteering_ their effort and their code, all
you're providing is an over-excess of hyperbole and punctuation. What
is frustrating to me is seeing people like yourself spend far more
time slamming these projects than actually contributing useful changes
back.

 

[rurpy]

Sorry for the outburst, but unfortunately, PIL is not alone in
this. Python is awash in poor documentation. [...]
I have to conclude that the problem with Python docs
is somehow "systemic"...

Yes, if everyone else disagrees with you, the problem is obviously
"systemic".

No, not everyone disagrees with him. There are many people who
absolutely agree with him.

What helps are concrete suggestions to the package maintainers about
how these improvements could be made, rather than huge sprawling
attacks on the state of Python documentation (and trying to tie it
into the state of Python itself) as a whole. ]

Nothing you quoted of what he wrote attempted to "tie it into the
state of Python itself"

Instead, what we get are
huge pointless rants like yours whenever someone finds that something
isn't spelled out for them in exactly the way that they want.

He never complained about spelling choices.

These people are _volunteering_ their effort and their code,

Yes, we all know that.

all
you're providing is an over-excess of hyperbole

It is hardly convincing when one criticizes hyperbole with hyperbole.

and punctuation. What
is frustrating to me is seeing people like yourself spend far more
time slamming these projects than actually contributing useful changes
back.

Face the facts dude. The Python docs have some major problems.
They were pretty good when Python was a new, cool, project used
by a handful of geeks. They are good relative to the "average"
(whatever that is) open source project -- but that bar is so low
as to be a string lying on the ground.

Your overly defensive and oppressive response does not help.
All it (combined with similar knee-jerk responses) does is
act to suppress any criticism leaving the impression that
the Python docs are really great, an assertion commonly made
here and often left unchallenged. Responses like yours
create a force that works to maintain the status quo.

 

[Thomas Jollans]

Face the facts dude. The Python docs have some major problems.
They were pretty good when Python was a new, cool, project used
by a handful of geeks. They are good relative to the "average"
(whatever that is) open source project -- but that bar is so low
as to be a string lying on the ground.

Actually, the Python standard library reference manual is excellent. At least
that's my opinion.

Granted, it's not necessarily the best in the world. It could probably be
better. But that goes for just about every documentation effort there is.

What exactly are you comparing the Python docs to, I wonder? Obviously not
something like Vala, but that goes without saying. "kj" said that the Perl
docs were better. I can't comment on that. I also won't comment on the sorry
mess that the language "Perl" is, either.
There are a few documentation efforts that I recognize are actually better
than the Python docs: Firstly, the MSDN Library docs for the .Net framework.
Not that I refer to it much, but it is excellent, and it probably was a pretty
darn expensive project too. Secondly, the libc development manual pages on
Linux and the BSDs. Provided you know your way around the C library, they are
really a top-notch reference.

If you were comparing it to the Java standard library documentation, please
provide a link. I've tried and failed to find any coherent documentation of
the standard classpath that anything like approaches the quality of the Python
documentation.

 

[Paul Rubin]

Actually, the Python standard library reference manual is excellent. At least
that's my opinion....
What exactly are you comparing the Python docs to, I wonder? Obviously not
something like Vala, but that goes without saying.

I didn't know Vala had especially good docs. I think GCC's docs are
pretty good. Python's are mostly ok but have significant gaps. For
example, tkinter has been part of the stdlib for at least a decade but
is totally undocumented in the Python library manual.

 

[Thomas Jollans]

I didn't know Vala had especially good docs.

Sorry for being imprecise. Let me clarify: they're practically non existent.
The language docs are okay if you know C#, but there are no API docs that are
more than auto-generated lists of classes and methods.

 

[Terry Reedy]

example, tkinter has been part of the stdlib for at least a decade but
is totally undocumented in the Python library manual.

I have trouble equating 'totally undocumented' to about 400 lines + 200
for tix + 600 for ttk ;-). Yes, 400, while more than most modules get,
is inadequate as a complete reference. But no one has volunteered to
reproduce the material available elsewhere. I am not sure that that is
the highest priority for doc improvement yet. You are welcome to have a
go at expanding the tkinter page.

 

[Nobody]

Actually, the Python standard library reference manual is excellent. At
least that's my opinion.

The core library documentation isn't as bad as most Python documentation,
but it's still far from adequate for core language functionality.

Anyone who thinks that the library documentation is "good" has become too
accustomed to FOSS "documentation" which is little more than an HTMLified
copy of the header files, with each function's documentation consisting of
a prototype and a one-sentence description which provides no information
which couldn't have been guessed from the function name.

For add-ons, you can get away with second-rate documentation. If the
documentation isn't sufficient to allow the module to be used, don't
use it; write your own instead. But that doesn't work for core language
features.

 

[Terry Reedy]

The Python docs have some major problems.

And I have no idea what you think they are.

I have participated in 71 doc improvement issues on the tracker. Most of
those I either initiated or provided suggestions. How many have you
helped with?

 

[rurpy]

Actually, the Python standard library reference manual is excellent. At least
that's my opinion.

Granted, it's not necessarily the best in the world. It could probably be
better. But that goes for just about every documentation effort there is.

What exactly are you comparing the Python docs to, I wonder? Obviously not
something like Vala, but that goes without saying. "kj" said that the Perl
docs were better. I can't comment on that. I also won't comment on the sorry
mess that the language "Perl" is, either.
There are a few documentation efforts that I recognize are actually better
than the Python docs: Firstly, the MSDN Library docs for the .Net framework.
Not that I refer to it much, but it is excellent, and it probably was a pretty
darn expensive project too. Secondly, the libc development manual pages on
Linux and the BSDs. Provided you know your way around the C library, they are
really a top-notch reference.

The Postgresql docs have always seemed pretty good to me. And I'll
second
kj's nomination of Perl. The Perl docs have plenty of faults but
many
years ago I was able to learn Perl with nothing more than those docs.
It
was well over five years later that I ever got around to buying a
commercial
Perl book. In contrast, I made several, honest efforts to learn
Python
the same way but found it impossible and never got a handle on it
until
I bought Lutz's and Beazley's books. (Of which Bealey's was by far
the
most useful; Lutz became a doorstop pretty quickly. And yes, I knew
about
but didn't use the tutorial -- tutorials are one way of presenting
information
that aren't appropriate for everyone or in every situation, and the
existence
of one in no way excuses inadequate reference material.)

If one is comparing the Python docs to others, comparing it to
Beazley's
book is informative. Most of the faults I find with the book are the
places
he took material from the Python docs nearly verbatim. The material
he
interprets and explains (usually quite tersely) is much clearer that
similar material (if it even exists) in the Python docs.

Finally, it it not really necessary to compare the Python docs to
others
to make a judgment -- simply looking at the hours taken to solve some
problem that could have been avoided with a couple more sentences in
the
docs -- the number of hours spent trying figure out some behavior by
pouring over the standard lib code -- the number of times one decides
how
to write code by "trying it", with fingers crossed that one isn't
relying
on some accidental effect that will change with the next version or
platform -- these can give a pretty good indication of the magnitude
of the doc problems.

I think one reason for the frequent "Python docs are great" opinions
here
is that eventually one figures out the hard way how things work, and
tends
to rely less on the docs as documentation, and more as a memmonic.
And
for that the existing docs are adequate.

 

[rurpy]

And I have no idea what you think they are.

I have written about a few of them here in the past. I sure Google
will
turn up something.

I have participated in 71 doc improvement issues on the tracker. Most of
those I either initiated or provided suggestions. How many have you
helped with?

Certainly not 71. But there is, for example, http://bugs.python.org/issue1397474
Please note the date on it.

 

[Terry Reedy]

Certainly not 71. But there is, for example, http://bugs.python.org/issue1397474
Please note the date on it.

Ugh. Some doc issues get resolved in hours. That didn't. I built on your
proposed change and properly assigned the issue, so it is more likely to
get attention. Please comment there on my revision.