search

ContinuumIO / anaconda-issues

Anaconda issue tracking
646 stars 220 forks source link

tkinter fonts #6833

Open kalefranz opened 6 years ago

kalefranz commented 6 years ago

From @marcogullieuszik on October 22, 2017 22:20

I have a simple Tk GUI (using ttk) that looks really bad when I use the conda python. the fonts are really bad. On the same computer, it looks ok if I use the system python.

Copied from original issue: conda/conda#6213

marcogullieuszik commented 6 years ago

tkk

In the upper window there is the output of python conda, in the lower one the system python

Current conda install:

           platform : linux-64
      conda version : 4.3.30
   conda is private : False
  conda-env version : 4.3.30
conda-build version : not installed
     python version : 3.6.3.final.0
   requests version : 2.18.4
   root environment : /home/marco/miniconda3  (writable)
default environment : /home/marco/miniconda3
   envs directories : /home/marco/miniconda3/envs
                      /home/marco/.conda/envs
      package cache : /home/marco/miniconda3/pkgs
                      /home/marco/.conda/pkgs
       channel URLs : https://repo.continuum.io/pkgs/main/linux-64
                      https://repo.continuum.io/pkgs/main/noarch
                      https://repo.continuum.io/pkgs/free/linux-64
                      https://repo.continuum.io/pkgs/free/noarch
                      https://repo.continuum.io/pkgs/r/linux-64
                      https://repo.continuum.io/pkgs/r/noarch
                      https://repo.continuum.io/pkgs/pro/linux-64
                      https://repo.continuum.io/pkgs/pro/noarch
        config file : None
         netrc file : None
       offline mode : False
         user-agent : conda/4.3.30 requests/2.18.4 CPython/3.6.3 Linux/4.8.0-58-generic debian/stretch/sid glibc/2.23    
            UID:GID : 1000:1000

#############

asn1crypto                0.22.0           py36h265ca7c_1    defaults
astropy                   2.0.2            py36ha51211e_4    defaults
astroquery                0.3.5                    py36_2    astropy
beautifulsoup4            4.6.0            py36h49b8c8c_1    defaults
bleach                    2.0.0            py36h688b259_0    defaults
ca-certificates           2017.08.26           h1d4fec5_0    defaults
certifi                   2017.7.27.1      py36h8b7b77e_0    defaults
cffi                      1.10.0           py36had8d393_1    defaults
chardet                   3.0.4            py36h0f667ec_1    defaults
conda                     4.3.30           py36h5d9f9f4_0    defaults
conda-env                 2.6.0                h36134e3_1    defaults
cryptography              2.0.3            py36ha225213_1    defaults
cycler                    0.10.0           py36h93f1223_0    defaults
dbus                      1.10.22              h3b5a359_0    defaults
decorator                 4.1.2            py36hd076ac8_0    defaults
entrypoints               0.2.3            py36h1aec115_2    defaults
expat                     2.2.4                hc00ebd1_1    defaults
fontconfig                2.12.4               h88586e7_1    defaults
freetype                  2.8                  h52ed37b_0    defaults
glib                      2.53.6               hc861d11_1    defaults
gmp                       6.1.2                hb3b607b_0    defaults
gst-plugins-base          1.12.2               he3457e5_0    defaults
gstreamer                 1.12.2               h4f93127_0    defaults
html5lib                  0.999999999      py36h2cfc398_0    defaults
icu                       58.2                 h211956c_0    defaults
idna                      2.6              py36h82fb2a8_1    defaults
intel-openmp              2018.0.0             h15fc484_7    defaults
ipykernel                 4.6.1            py36hbf841aa_0    defaults
ipython                   6.1.0            py36hc72a948_1    defaults
ipython_genutils          0.2.0            py36hb52b0d5_0    defaults
ipywidgets                7.0.0            py36h7b55c3a_0    defaults
jedi                      0.10.2           py36h552def0_0    defaults
jinja2                    2.9.6            py36h489bce4_1    defaults
jpeg                      9b                   habf39ab_1    defaults
jsonschema                2.6.0            py36h006f8b5_0    defaults
jupyter                   1.0.0            py36h9896ce5_0    defaults
jupyter_client            5.1.0            py36h614e9ea_0    defaults
jupyter_console           5.2.0            py36he59e554_1    defaults
jupyter_core              4.3.0            py36h357a921_0    defaults
keyring                   10.4.0           py36h4fce1c9_0    defaults
libedit                   3.1                  heed3624_0    defaults
libffi                    3.2.1                h4deb6c0_3    defaults
libgcc                    7.2.0                h69d50b8_2    defaults
libgcc-ng                 7.2.0                h7cc24e2_2    defaults
libgfortran               3.0.0                         1    defaults
libgfortran-ng            7.2.0                h9f7466a_2    defaults
libiconv                  1.15                 h63c8f33_5    defaults
libpng                    1.6.32               hda9c8bc_2    defaults
libsodium                 1.0.13               h31c71d8_2    defaults
libstdcxx-ng              7.2.0                h7a57d05_2    defaults
libxcb                    1.12                 h84ff03f_3    defaults
libxml2                   2.9.4                h6b072ca_5    defaults
libxslt                   1.1.29               hcf9102b_5    defaults
lxml                      4.1.0            py36h5b66e50_0    defaults
markupsafe                1.0              py36hd9260cd_1    defaults
matplotlib                2.1.0            py36hba5de38_0    defaults
mistune                   0.7.4            py36hbab8784_0    defaults
mkl                       2018.0.0             hb491cac_4    defaults
nbconvert                 5.3.1            py36hb41ffb7_0    defaults
nbformat                  4.4.0            py36h31c9010_0    defaults
ncurses                   6.0                  h06874d7_1    defaults
notebook                  5.0.0            py36h0b20546_2    defaults
numpy                     1.13.3           py36ha12f23b_0    defaults
openssl                   1.0.2l               h077ae2c_5    defaults
packaging                 16.8             py36ha668100_1    defaults
pandoc                    1.19.2.1             hea2e7c5_1    defaults
pandocfilters             1.4.2            py36ha6701b7_1    defaults
path.py                   10.3.1           py36he0c6f6d_0    defaults
pcre                      8.41                 hc71a17e_0    defaults
pexpect                   4.2.1            py36h3b9d41b_0    defaults
pickleshare               0.7.4            py36h63277f8_0    defaults
pip                       9.0.1            py36h8ec8b28_3    defaults
prompt_toolkit            1.0.15           py36h17d85b1_0    defaults
ptyprocess                0.5.2            py36h69acd42_0    defaults
py                        1.4.34           py36h0712aa3_1    defaults
pycosat                   0.6.2            py36h1a0ea17_1    defaults
pycparser                 2.18             py36hf9f622e_1    defaults
pygments                  2.2.0            py36h0d3125c_0    defaults
pyopenssl                 17.2.0           py36h5cc804b_0    defaults
pyparsing                 2.2.0            py36hee85983_1    defaults
pyqt                      5.6.0            py36h0386399_5    defaults
pysocks                   1.6.7            py36hd97a5b1_1    defaults
pytest                    3.2.1            py36h11ad3bb_1    defaults
python                    3.6.3                hc9025b9_1    defaults
python-dateutil           2.6.1            py36h88d3b88_1    defaults
pytz                      2017.2           py36hc2ccc2a_1    defaults
pyzmq                     16.0.2           py36h3b0cf96_2    defaults
qt                        5.6.2               h974d657_12    defaults
qtconsole                 4.3.1            py36h8f73b5b_0    defaults
readline                  7.0                  hac23ff0_3    defaults
requests                  2.18.4           py36he2e5f8d_1    defaults
ruamel_yaml               0.11.14          py36ha2fb22d_2    defaults
scipy                     0.19.1           py36h9976243_3    defaults
setuptools                36.5.0           py36he42e2e1_0    defaults
simplegeneric             0.8.1            py36h2cb9092_0    defaults
simplejson                3.11.1                   py36_0    defaults
sip                       4.18.1           py36h51ed4ed_2    defaults
six                       1.11.0           py36h372c433_1    defaults
sqlite                    3.20.1               h6d8b0f3_1    defaults
terminado                 0.6              py36ha25a19f_0    defaults
testpath                  0.3.1            py36h8cadb63_0    defaults
tk                        8.6.7                h5979e9b_1    defaults
tornado                   4.5.2            py36h1283b2a_0    defaults
traitlets                 4.3.2            py36h674d592_0    defaults
urllib3                   1.22             py36hbe7ace6_0    defaults
wcwidth                   0.1.7            py36hdf4376a_0    defaults
webencodings              0.5.1            py36h800622e_1    defaults
wheel                     0.29.0           py36he7f4e38_1    defaults
widgetsnbextension        3.0.2            py36hd01bb71_1    defaults
wxPython                  4.0.0b1                   <pip>
xz                        5.2.3                h2bcbf08_1    defaults
yaml                      0.1.7                h96e3832_1    defaults
zeromq                    4.2.2                hb0b69da_1    defaults
zlib                      1.2.11               hfbfcf68_1    defaults
boffi commented 6 years ago

At least on my Debian Sid system, Anaconda's Tk interpreter DLL, that ultimately deals with placing things on screen, libtk6.0.so, is not built against the Freetype library so what you can use are essentially the legacy, bitmapped X fonts that are available on your system.

The issue with tkinter fonts could be solved if and only if Anaconda includes Freetype support in the Tk DLL.

Could this be done? Every half-decent Linux distribution ships a Tk DLL that supports Freetype, so I would say yes, it could be done — but of course I may ignore the issues involved in the specific case of an Anaconda build.

A WORKAROUND, definitely NOT A SOLUTION, is to make a symlink from Anaconda's libtk6.0.so (after a backup, of course) to the system's one. I've not made an extensive testing but looks like it works.

mingwandroid commented 6 years ago

No we cannot do this. When building our software we need python built very early, well before anything graphical gets built. Adding Freetype as a dep for tkinter causes a cycle in the build graph and we can no longer build the distro.

Why not use something more modern than tkinter anyway?

boffi commented 6 years ago

@mingwandroid

No we cannot do this.

First of all, thank you for answering so clearly. That said, it's very sad that you cannot build tkinter in a sane manner.

Why not use something more modern than tkinter anyway?

tkinter is based on Tk

Regards, gb

PS: and, from a more personal angle, I started with tcl/tk way before I had met Python... :-)

haomingw commented 6 years ago

same problem when I use git-gui, the font gets worse every time I update anaconda

smithsp commented 6 years ago

Note that I solved this by rebuilding the tk package, adding freetype to the build and run requirements. conda install -c smithsp tk

haomingw commented 6 years ago

I resolved this issue by removing wish files in ANACONDA_PATH/bin and related virtual environments

Tcll commented 6 years ago

just to throw my 2 cents on here Why not use something more modern than tkinter anyway?

I'm running 4 anaconda environments for windows (wine) and linux x86 and x64 for testing running IDLE on each relies on tkinter, so you're kinda stuck with only the 20 ugly fonts to select from...

Linux: (ugly font: courier 10 pitch) Windows: (nice font: Courier New) (I broke 64bit, may as well just update to 2.5.0 when I can get to it)

why use IDLE?

I would prefer not to use IDEA for everything as I don't always need that power, and even then I don't exactly have the ease I do with IDLE:

tysonclugg commented 5 years ago

@mingwandroid wrote:

No we cannot do this. When building our software we need python built very early, well before anything graphical gets built. Adding Freetype as a dep for tkinter causes a cycle in the build graph and we can no longer build the distro.

Strictly speaking you are correct, but practically there are ways around the issue of cyclic dependencies.

One way that could work involves building a new minimal dependency tkinter-minimal early in the build without any GUI dependencies, then building the full tkinter later in the build process with Freetype support.

Yes, it involves some futzing about, but it would make your users very happy...

zklaus commented 5 years ago

One way that could work involves building a new minimal dependency tkinter-minimal early in the build without any GUI dependencies, then building the full tkinter later in the build process with Freetype support.

Yes, it involves some futzing about, but it would make your users very happy...

Sounds like @tysonclugg proposes a practical solution to a very annoying problem. Any chance of this moving forward?

mingwandroid commented 5 years ago

Sounds like @tysonclugg proposes a practical solution to a very annoying problem. Any chance of this moving forward?

The workaround is not practical for us. Our package manager and build infrastructure cannot handle this - actually none I've ever seen can. We cannot introduce cycles in our dependency graph and this doesn't solve that (except to call it "some futzing") To be clear you need python to build good font rendering libraries so python cannot depended upon the same. These mentioned 'earlier in the build process' vs 'later in the build process' regions of time which can be used to fix this simply do not exist. We have a package called python and it is required to build freetype (etc, it's probably glib that requires python though) so freetype cannot be a dependency of python without having code to carefully untangle this in the core of conda-build, making temporary packages right through the dep cycle.

If you want to have a go at adding that feature this would be great. I'll be happy to advise but it would be very difficult.

Personally I don't find this issue annoying in the least though. I can stare at poorly rendered fonts for hours on end.

Tcll commented 5 years ago

if freetype is so hard to implement by itself, then what about gdi32??

I've been looking into it's frontend for a bit now to create windows without tkinter... (I have portable interpreters for various platforms distributed with my program, the smaller I can make them, the better) ^ for an example, Win x86 Py34 is only 12 MiB

but getting back on topic, gdi32 fonts are actually rendered using freetype

unfortunately though I can't write this support for this as I don't have experience with C (if I could I'd write it for Py34) but hopefully informing the anaconda devs about it will encourage them to take new paths. :)

msarahan commented 5 years ago

I think this would be possible if we had a python-base package that used the minimal, ugly build, and added the freetype dep to the full python package. We have wanted something similar to remove a terrible hack about automatically adding pip to any python dependency. It is quite a lot of work, though, because many recipes will need to be updated and rebuilt to use the different dependency in build/host.

This said, this project is very low in priority for us. There are larger problems that we need to solve before this can be revisited. We'd gladly accept a PR. I recommend going through conda-forge for that, as their CI infrastructure makes these ideas easier to test.

delarosatrevin commented 5 years ago

Hum...I'm considering to use Anaconda for one of our projects...but it heavily use Tkinter and it is not easy to port to another graphical toolkit now. It is a bit disappointing that Tkinter is not supported with all its features. On other side, I understand the limitations about dependencies management during the build process. Anyway, maybe a naive question from my side..there is not any other clean way to get a Tkinter package installed with freetype (and png) support on top of an exiting conda-python build?

smithsp commented 5 years ago

@delarosatrevin Does my comment help? conda install -c smithsp tk

delarosatrevin commented 5 years ago

Thanks @smithsp for your suggestion, but it is not working for me. I did the following (in case you can find some mistake on it) First, create a new environment:

> conda create -n "testtk3" python=2.7.16

But this install default 'tk' package, so:

> conda remove tk # this remove Python
> conda install -c smithsp tk
> conda install python==2.7.16

But unfortunately it still show the crappy fonts with an small Tkinter application. I repeated the same test with Python3 and the same results. System Python (2.7.12 in Ubuntu16.04) does properly show the fonts for the same sample app.

Any suggestion?

smithsp commented 5 years ago

@delarosatrevin When it has worked for me, I did not do the conda remove tk step.

delarosatrevin commented 5 years ago

@smithsp , but if 'tk' is already installed, then trying to install it from your channel does not make any changes.

Collecting package metadata: done
Solving environment: done

# All requested packages already installed.
precesseur commented 5 years ago

Well, then, just forget conda. Numba was quite an incentive to use conda, but still there are other ways around, including, no, no joke Fortran 03 or 12 and cython. OK we are told that tkinter could be replaced by more modern UI. Well except that everybody have used tkinter for ages. I find unbelievable that the anteriority of one piece of software which had always faithfully worked, can be destroyed and swept away by 'no we cannot do it, because we use modern tools, just switch to that ones'...'and if you are not happy just walk away'. Barh! it's what i'll do. This boots are made for walking ...

calroc commented 4 years ago

I just wanted to "+1" this bug. I'm using Tkinter and Conda and it's very ugly:

potato

I understand the trouble with circular build dependencies, it sounds terrible, but please pretty please...? Is there something I can do to help? I saw conda-forge mentioned above, I'll check that out.

smithsp commented 4 years ago

Try conda install -c smithsp tk==8.6.9. https://github.com/conda-forge/tk-feedstock/pull/40 is also relevant

BlackArbsCEO commented 4 years ago

@smithsp is this your custom build that plays nicely on linux? for clarification, is it cross platform also?

boffi commented 4 years ago

@smithsp I'm sorry but (at least on my Debian PC) it doesn't do


$ conda install -c smithsp tk==8.6.9
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: | 
Found conflicts! Looking for incompatible packages.                                     failed                                                                                      

UnsatisfiableError: The following specifications were found to be incompatible with each other:

Output in format: Requested package -> Available versions

Package tk conflicts for:
tk==8.6.9
python=3.7 -> tk[version='>=8.6.7,<8.7.0a0|>=8.6.8,<8.7.0a0']
smithsp commented 4 years ago

@boffi That is interesting. I am not sure why the python tk version check fails as 8.6.7<8.6.9<8.7.0a0.
@BlackArbsCEO It is only a linux build. (See https://anaconda.org/smithsp/tk/files) If you have time, you might push on https://github.com/conda-forge/tk-feedstock/pull/40 to get a different build.

calroc commented 4 years ago

I got what looks like the same error:

(icanhaztkfonts) sforman@bock:~$ conda install -c smithsp tk==8.6.9
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: \ 
Found conflicts! Looking for incompatible packages.
This can take several minutes.  Press CTRL-C to abort.
failed                                                                                                                                                                                                              

UnsatisfiableError: The following specifications were found to be incompatible with each other:

Output in format: Requested package -> Available versions

Package tk conflicts for:
tk==8.6.9
python=3.8 -> tk[version='>=8.6.8,<8.7.0a0']

And yeah, as far as I know, 8.6.9 >= 8.6.8 and 8.6.9 < 8.7.0 so...

calroc commented 4 years ago

@smithsp Thanks for pushing on this. I added a comment on the PR with my sad and pathetic GUI image, so hopefully that encourages someone to move things along. I wish I knew enough to help. It seems like your PR will do the trick, it just needs to get over the hump, eh?

Tcll commented 4 years ago

glad to see things hopefully finally moving along :) sadly I won't get to benefit unless they release a py34 build (matching my XP64 test env) but I'm pretty sure I'll be building my own standalone interpreter(s) before that miracle ever happens :P

hope the next update puts this issue to bed once and for all :)

xtotdam commented 2 years ago

I see a workaround for this disappointing problem, conda remove --force tk. This causes python from conda use system tk. However this causes also packages inconsistency. I wish conda devs could fix this little issue.

dlime commented 2 years ago

It is only a linux build. (See https://anaconda.org/smithsp/tk/files)

@smithsp is this still the case? Unfortunately I fail to set the package to my Linux environment and I suspect the reason is that here I can see only OSX build: https://anaconda.org/smithsp/tk

JubilantJerry commented 2 years ago

For me, this bug is not just an issue of whether I can accept staring at poorly rendered fonts for hours on end. I build applications that use non-English Unicode characters in tkinter, and the non-freetype fonts handle non-English glyphs very poorly. Text in my application appears with blank rectangles, uneven character sizes, and other formatting problems.

Force removing tk and creating an inconsistent environment is not acceptable. It defeats the purpose of conda in the first place and there doesn't seem to be some kind of exceptions list for force-removed packages. As of writing my comment my distro ships a version of tk that isn't compatible with the Python that I installed from conda (my version was 8.6.10, Python wanted at least 8.6.11). After force removing tk my application seemed to work, but I suspect the resulting combination is not stable. Similarly, I can't keep the tk package and simply make a symbolic link replacing the libtk8.6.so with my system one. Doing that actually creates an explicit error in tk about a version mismatch.

In the end, the workaround I used was to install the libxft dependencies (see here), rebuild tcl and tk from source to match the version that conda wanted, then copied libtk8.6.so to the lib directory of the environment.

There must be some method of addressing this that we're all happy with. Even if we can't directly change tk because of circular dependencies, maybe we can do something like this:

joba-1 commented 1 year ago

My own tkinter app looks ugly when used with conda environment - finally found the frustratingly longstanding truth :(

So it is admin happy xor user happy. In my case I'm both -> not happy :(

Others can build tk with nice fonts, I'm sure Anaconda can do it, too!

joba-1 commented 1 year ago

The smithsp way also does not work here. Thanks for the effort, anyways!

conda install -c smithsp tk==8.6.9
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Collecting package metadata (repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: - 
Found conflicts! Looking for incompatible packages.
This can take several minutes.  Press CTRL-C to abort.
failed                                                                                                                                                                               

UnsatisfiableError: The following specifications were found to be incompatible with each other:

Output in format: Requested package -> Available versions

Package tk conflicts for:
python=3.11 -> tk[version='>=8.6.12,<8.7.0a0']
tk==8.6.9The following specifications were found to be incompatible with your system:

  - feature:/linux-64::__glibc==2.31=0
  - feature:|@/linux-64::__glibc==2.31=0

Your installed version is: 2.31

Note that strict channel priority may have removed packages required for satisfiability.
ekurtgl commented 1 year ago

I believe this problem still persists. Any workarounds found so far? @mingwandroid

joba-1 commented 1 year ago

I believe this problem still persists. Any workarounds found so far? @mingwandroid

My workaround is dump conda for the python native penv.

I wrote a little script and usage info for downloading, compiling, installing, and using any python version with penv on linux (in parallel to what other pythons you or your distro might use). Zero issues for me so far. I didn‘t actively dump conda for it, but also never needed it anymore since then.

Here it is if you want to have a look: https://gist.github.com/joba-1/1b0ae5514cc2e448b184f6afbf29f6df

smithsp commented 12 months ago

I have introduced the tk_variant variant in https://github.com/conda-forge/tk-feedstock/pull/40 . I haven't heard from the conda-forge core devs yet if this is going to make it through their approvals.

bszollosinagy commented 10 months ago

@smithsp has solved it! It is already available from conda-forge: conda install -c conda-forge tk=*=xft_*

It works for me, even inside a Docker/Anaconda sandwitch. (but you do need a RUN apt-get install -y libxft2 in DockerFile to install XFT, but that is all)

thanks @isuruf for the install command!

PilotX-Maverick commented 10 months ago

This is what i could possibly build with the native Tkinter functions and some UI designs. I think this is the peak possible, for anything more, we need to shift to PyQt5 or higher libraries.

Screenshot 2023-10-17 163459