As part of work, I frequently remote login to my workstation from a different laptop every week or so. Powerline works perfectly with the patched fonts on the workstation itself, but it looks and works horrible if I don't have the patched fonts. The cursor is 2 characters to the left of the end of line and messes up my commands.
It's not really practical for me to keep installing fonts on every new machine that I login from. Is there a way to have powerline work without the fancy patched fonts and glyphs? I'd be happy if it just uses stock characters in a font like 'inconsolata' so that I can login remotely in peace.
Related
I'm using Apache Guacamole 1.2.0 and XRDP 0.9.12 on Ubuntu 20.04.
When looking at the remote desktop the fonts are shown sometimes reasonably sharp (alas still less than when opening an RDP connection directly), but often become blurry/blocky, as shown in the following screenshot.
It's possible to "provoke" this by letting the browser window loosing the input focus. But it also happens while working on the remote desktop. By triggerings repaints (e.g. by going with the mouse over the text) the fonts become sharp again at the repainted screen regions while staying blurry at the other screen regions.
The RDP connection settings in Guacamole are configured like this:
I played a bit with the font smoothing and caching options, but could not improve the situation.
Is there any way to keep the fonts from "going blurry"?
Best regards,
Bernd
I reinstalled with compiled versions xrdp 0.9.14 and xorgxrdp 0.2.14 - I had to do this anyway, because file sharing does not work between Guacamole and xrdp 0.9.12.
As a "side effect", the blocky/blurry appearance is gone now, too.
Either it has been fixed with the newer version or my old installation was somehow faulty.
We use SATO CL412e printers to print labels (3x7), with the label coming from a local SSRS report. Until recently, this setup worked without issue. A few months ago we modified the label, and implemented (new implementation) at one site (Site A). Then a few weeks ago, we pushed the change out to another site (Site B) that had previously been using this label (old version). Since we did this, the label at Site B is... weird.
The barcode is quite clearly not right, and all the normal characters are squished together, and perhaps bolded. Theoretically, we have proved that it is not the application (which recently changed as well) or the label report because it works fine at Site A, as well as from a different printer (same model, same drivers, etc.) at Site B.
Yesterday the drivers at Site B were updated to match Site A, which resulted in no change. This morning we found a few settings in the web interface that were different. I have not heard yet, but I seriously doubt it will have an effect.
What am I missing? To date, this exactly configuration works on three printers, and fails on one. I am at a complete loss as to what to check next. What could possibly cause this behavior?
Edit:
It has been discovered that this happens only through RDP. When we use a Citrix connection to the same server, we have no problem. It has been suggested that maybe this is a problem with the Internet Explorer settings. Any basis to this, and what settings?
RDP has a feature which connects your local printers to the remote server. This can mean the printer you get when connected with RDP is different than the printer when you are locally working on that server, or using Citrix. It's possible your local workstation has the same printer defined with different settings.
In your RDP connection dialog, click "Settings" and click the "Local resources" tab. Then clear the "Printers" checkbox to prevent this behavior.
For web development on localhost I'm using domains with .loc extension at the end of a domain name.
For example: if I work on a site roses.com, the local development domain would be roses.loc
(defined in hosts file and IIS as a host-header in binding)
My preferred browser (the main browser I use for development is Chrome) but unfortunately
it does not recognize a domain name with .loc extension as http://rose.loc - it throws me onto a google search page each time I would type in rose.loc (without http://) in the beginning..
Have you experienced this in a similar way ? Is there some solution to that ?
Because during intensive development testing with clearing browser cache and restarting the browser for various reasons, it's getting pretty annoying to be thrown at a google search page instead of the development page where I expect to notice some changes, each time I forget to type in http:// before the url (and Chrome is the one who hides it by default, anyway..)
Google Chrome is pretty "smart" with this. It uses a list of known-good TLDs and assumes everything else is just a search term that happens to end in a dot followed with some characters.
99% of the time that's perfectly fine. It's "only" us developers and a few people with strange network setups that have to suffer for the good of the majority ;-)
You can try using .local as your TLD, as that's a defined domain for referencing local domain names (at least it's used in some mDNS systems).
The issue has been entered as #30636 in the Chromium bug tracker. One workaround that often (but not always) seems to work is to append / to your hostname. So try roses.loc/.
I've created a search engine with a keyword of 'l' (my local TLD is .l). The URL for the search engine is http://%s.l. Then, I simply type "l mysite" in the address bar and it takes me to mysite.l.
Here is a workaround I came up with for this bug: http://code.google.com/p/chromium/issues/detail?id=30636#c38
I have Chromium installed on Linux Mint, and have a few localhost websites here. (I use Firefox for all of my work, so I have just discovered something here with Chromium.) My local sites are called morse and a.z. I had to enter http://morse/ and a.z/ respectively to get these sites to load the first time. They produced quick links on the new tab's otherwise blank page.
After closing Chromium, I reopened it and I could enter just morse/ and a.z to visit these sites. Since I've never seriously used this browser, I have not tailored any settings in it. (I did not use the quick link icons, but instead typed in the address bar.)
My findings confirm the localhost example.TLD/ entry does work when entered for the first time.
About Chromium: I am using Version 106.0.5249.119 (Official Build) for Linux Mint (64-bit).
We use the Microsoft Report Viewer control in our web application to print checks. The report needs to use a special MICR bank font in the report. Something like this: http://www.micrfonts.com/
Anyways the font is just a regular TTF font installed in Windows.
Now, when testing the printing on my local setup, everything works perfectly. The checks print on my personal LaserJet using the font correctly.
However, at my client's site, he is telling me that the font is rendering in the web-browser OK, which I think confirms that he has the proper font installed on his machine, but when he sends the report to the printer, the printout does not use the correct font.
Are there any limitations with the RDLC printing with regards to non-standard fonts? I'm not sure how to troubleshoot this issue.
Any help would be appreciated.
More details that I just discovered:
Apparently, everything works from my PC if I connect to my local instance of the app on localhost.
However, if I connect to my app on our remote dev environment, I can replicate the issue of the font not properly printing.
Figured it out. Apparently the font needs to be installed both on the client, and on the webserver.
When rendering to screen, the report viewer uses Html, so the font needs to be on the client machine. However, when printing, the report is generated server side before being sent to the printer, so in that case, the font needs to exist on the server, otherwise it will be substituted.
Took a while to find this. Hope this helps someone else.
I have a custom Firefox add-on. It worked ok, until we decided to make it self update-able.
According to manuals at mozilla.org, there should be an <em:updateURL> entry in add-on's install.rdf, containing a link to some update.rdf. Seems pretty simple.
But, when I add <em:updateURL>some_url</em:updateURL>, the add-on doesn't work. I use Netbeans IDE with Foxbeans plugin for development, and when I run add-on project from this IDE, Firefox runs with this add-on switched off (and switching on disabled). When I compile the XPI and add it to Firefox (3.6.12), it says about version incompatibility and doesn't work either. Doesn't matter, if I use http or https in the updateURL.
If this tag is empty, like this: <em:updateURL></em:updateURL> , everything works (but doesn't update itself, of course)
The solution was quite simple, though not obvious at a first glance.
In install.rdf <em:updateURL> should be after <em:targetApplication>, not before.
Hope this would help somebody, sometime.