cannot open resource about word_cloud HOT 24 CLOSED

On my windows 7 machine, specifying font_path='C:\Windows\Fonts\msyh.ttf' works well. I am generating word cloud for Chinese characters. FYI.

from word_cloud.

import os
os.path.exists('/Users/paul/Library/Fonts/Verdana.ttf')

True

from word_cloud.

Hi, I have that same problem too on Mavericks, with a font I just installed via brew, did you solve it?

from word_cloud.

I found the problem: the font_path argument must also be passed to the wordcloud.draw function (I made exactly the same error as you). I don't know how, but I feel the API should let us specify the font location in a friendlier way.

from word_cloud.

You are right, at the moment some options have to be specified twice. That is no good. I didn't review this refactoring as much as I should. I'll try to fix this soonish.

from word_cloud.

Perhaps a class would be more appropriate in this case (instead of standalone functions)? A way to access the resulting img (instead of saving it to a file) would also be nice, especially in a notebook environment.

from word_cloud.

I totally agree that the current way to get the outputs is suboptimal. I'll see what I can come up with. I definitely also want a way to fix the random seeds.

from word_cloud.

I switched around the interface and I'll close this issue. Still I'd love to hear what you think of the new version.

from word_cloud.

I ran into this problem on OSX today. WordCloud hard codes the default font to /usr/share/fonts/truetype/droid/DroidSansMono.ttf. This was my fix (hack):

-FONT_PATH = "/usr/share/fonts/truetype/droid/DroidSansMono.ttf"
+FONT_PATH = "/Library/Fonts/Georgia.ttf"

It would be relatively easy to do a quick platform check using sys.platform. This could be used to make the library more windows compatible as well.

Great tool though!

from word_cloud.

@jjduhamel Since the first version, there is an option to set the font path, so you don't need to hack anything. You are right, it would be convenient to have other default options. The main reasons I didn't do that before is because I didn't have default locations for fonts on other systems, and the path needs to be changed anyhow if you want to change the font.
Is there a version-independent way to get a font in Windows?

from word_cloud.

See this thread on how to do it properly. I'm not going to do it properly, feel free to do a pull requestion. I could create a list of a couple of good bets that could be tried by default, though.

from word_cloud.

An alternative possibility would be to use the fonts installed by matplotlib, which would add a matplotlib dependency, though. Maybe adding a dependency on fonttools would be better.

from word_cloud.

maybe you can grab a font from http://www.fontsquirrel.com/ that allows you to embedd it in software and just use the relative path. So it should work on any OS.

from word_cloud.

good point.

from word_cloud.

I think it's important to use the system fonts. I'll try to implement this, but I can't promise I'll have time. Also, yeah I overlooked the font_path arg in the constructor. It would still be nice to make a change though because running the examples won't work on Mac or Windows which will scare users away.

from word_cloud.

why do you think it is important to use system fonts?
The only way to really make it work on Windows is to includ fonttools. look at their code and what they do to find the fonts. This is really non-trivial.

from word_cloud.

I just tried the new class-based version, and it's much better (in particular, the to_image method is very useful). One minor detail though: why is the _fit_words method considered "internal" (i.e. has a leading undescore)? In my application (extracting words from a gensim.LDA model) I'm using it, and I assume similar use cases would not be so rare. But anyway, great work, thanks!

from word_cloud.

I'm trying to use this on a website and I need to use fonts that are consistent across different tools/programming languages.

I don't really care if it works on windows. I'd like it to support OS X as well because that's what I develop on. I'm looking into using the fontconfig library for that.

Sent from my iPhone

On Sep 25, 2014, at 9:48 AM, Andreas Mueller [email protected] wrote:

why do you think it is important to use system fonts?
The only way to really make it work on Windows is to includ fonttools. look at their code and what they do to find the fonts. This is really non-trivial.

—
Reply to this email directly or view it on GitHub.

from word_cloud.

What do you mean by "consistent across tools/programming languages"? You will not have Times on Linux and you won't have Nimbus on OS X. So even if you can find what fonts are installed, they will not be the same. If you use an open font that is easily accessible it will be much easier to be consistent. And other tools can use it too.

from word_cloud.

@cjauvin I wasn't quite sure about whether they should be public or private. I just made them public again after your comment. How are you using this together with lda? I have long be wanting to do coloring using topic models.
FYI there is an __array__ method, so if you use numpy or matplotlib you can just use the WordCloud object as an array (plt.imshow(worcloud) works).

from word_cloud.

I’m using different tools to generate graphics for my site. I may have some tools written in perl or ruby, and I want to be able to use the same fonts in all tools.

I put something together that uses the Python-fontconfig package to manage font-paths. Furthermore, this allows you to only specify the name of the font, without knowing it’s path. Fontconfig is standard on Linux and can be installed on OSX using tools like Homebrew or compiled from the source.

I submitted a pull request for this. Feel free to ask me to make changes before you merge, or let me know if you prefer a different approach altogether.

On Sep 29, 2014, at 2:31 PM, Andreas Mueller [email protected] wrote:

What do you mean by "consistent across tools/programming languages"? You will not have Times on Linux and you won't have Nimbus on OS X. So even if you can find what fonts are installed, they will not be the same. If you use an open font that is easily accessible it will be much easier to be consistent. And other tools can use it too.

—
Reply to this email directly or view it on GitHub.

from word_cloud.

Hi everyone, and @balzer82 in particular.
I just came across this issue while trying out the simple example coming with the library.

Instead of changing the way the hardcoded font works like @jjduhamel has suggested above, you can simply provide the font_path to the WordCloud object you're creating.

The line that didn't work (Win7, Python 2.7) was:

wordcloud = WordCloud().generate(text)

When I changed it to:

wordcloud = WordCloud(font_path='Verdana.ttf').generate(text)

It worked. If you browse the PIL sources that throw the IOError you'll see that PIL is actually looking for that font name in the win32 font folder, and is thus platform dependent. Apparently, it is also possible to pass the object an absolute font_path, which turns out to be equivalent to changing the hard-coded path (but much more flexible).

Cheers,
Florian

from word_cloud.

Yosemite:

Download Verdana.tff, move it to /Users/[user]/Library/Fonts/

specify:
wordcloud = WordCloud(font_path='/Users/[user]/Library/Fonts/Verdana.ttf').generate(text)

works

from word_cloud.

Thanks @flipdazed, thats it!

from word_cloud.