I have MonoDevelop running quite well on Linux Fedora 27. My only real gripe is that some of the IDE text are ridiculously tiny and often challenging to read. This occurs in the tabs headings and status window.
I looked around in the Edit | Preferences | Fonts, but it only has three controls: Text editor, General pad text, and Output pad text. These are all set at 10 or 11 point (not 1 or 2 as it would seem to be); changing all of them to larger values did not affect the tiny text areas.
This behavior might be related to the laptop's 4K monitor (3840 x 2160 pixels). The console text appearing while the system boots is similarly challenging to read.
Ideas? Suggestions?
Related
I have a web app with a form in it. The form in turn has a select element with options containing a bunch of users' info, their names being set as the label/content of the option elements.
Now apparently one of the users' parents think it's fun to give their child a name with 3000 characters of gibberish in it.
I wouldn't want to make his life any harder than it is, but unfortunately I'll have to remove his account because the long name seems to introduce some interesting limitations on browsers that I didn't know about.
I started highly scientific testing using this fiddle with a few browsers in two computers and found out that
Chrome v50 (64bit) displayed a black box instead of the dropdown when the label length hit 1510
FF v46 refused to open the dropdown at all when the content length was 2716
IE v11 doesn't even break a sweat with tens of thousands of characters
Chrome v49 was the least fun of all. It rendered the whole window and all the other open tabs fully black so I had to close them all and start again. Didn't bother to find the exact limit for that
It seems though that the actual limits are much more related to the content width and not the length, as changing the character from "a" to "i" using proportional font affected the results.
The question: is there a reason Chrome and FF flip out with content of this size? Is there a specific limit on how long/wide the option's label can be (other than the subjective opinions about aesthetic/usable form inputs)?
I work for an engineering design house and we store black and white design drawings in TIFF format compressed with CCITT Group 4 compression.
I am working on a project to improve our software for working with these drawings. I need to be able to load the raw data into my program obviously, so I must decompress it.
I tried using LibTiff but gave up on that rather quickly. It wouldn't build, generating over 2000 errors. I found many obvious syntax errors in the library and concluded it was junk. I spent about 3 hours trying to find the part of the library that implements the CCITT Group 4 codec but no luck, that code is an incomprehensible mess.
So it is that I am writing my own codec for the program. I have it mostly working well, but I am stuck on a problem. I cannot find good documentation on this format. There are a lot of good overviews that describe generally how 2D Modified Huffman compression works, but I cant find any that have specific, implementation level details. So I am trying to work it out by using some of the drawing files as examples.
I have vertical and pass modes working well and my algorithm decompresses about a third of the image properly before it goes off to the wizard and produces garbage.
I traced the problem to the horizontal mode. My algorithm for the horizontal mode expects to see the horizontal mode code 001 followed by a set of makeup codes (optional) and a termination code in the the current pen color, followed by another set of makeup codes (optional) and a termination code in the opposite color.
This algorithm worked well for a third of the way through the image, but suddenly I encountered a horizontal mode run where the opposite color comes before the current pen color.
The section of the image is a run of 12 black pixels followed by a run of 22 white pixels.
The code bits from that section are 00100000110000111 which decodes to Horizontal (001) 22 White (0000011) 12 Black (0000111 ) which as you can see is opposite of the order in which the pixels appear in the image.
Since my algorithm expects image order listing, it crashes. But the previous 307 instances of horizontal mode in this same image file were all in image order. This is the only reversed one I have found (so far).
Other imaging programs display this file just fine. I tried manually editing the bits in the image file just as a test to put the order in image order and that causes other imaging programs to crash when decoding the image. This leads me to believe they have some way of knowing that it is reversed in that instance.
Anyone know specific implementation level details about this TIFF CCITT G4 encoding which could help me understand how and why the run codes are sometimes reversed?
Thanks
Josh
CCITT G4 horizontal codes are always encoded as a pair (black/white) or (white/black). It depends on the current pen color. A vertical code will flip the color, but a horizontal code will leave the color unchanged. If the current pen color is black, then you decode a white horizontal code followed by a black. If the current pen color is white, then you will do the opposite.
Code : 00100000110000111
001 : Horizontal Mode
0000011000 : Black RunLength 17
0111 : White RunLength 2
It is Black first.
Run codes are not reversed.
In my Windows Phone 8 app the app bar usually looks like this:
But for some reason on one of my users with a 1020 it looks like this: (it's a NOKIA RM-877_nam_att_205 3.3.0.2 3051.40000.1346.0001 with OS version 8.0.10517.0)
(the WP8 emulator also looks like the second one)
Anyone knows why this happens, and how can I fix it?
The default behaviour of English text accompanying an ApplicationBarIconButton is for it to be on a single line.
Multi-line support was added for some languages where word length is typically longer than in English. The wrapping was therefore needed for text to not be clipped.
The enabling of multi-line support is dependent upon a combination of device, OEM and regional settings. Developers/apps cannot influence this behaviour.
The expectation of all English text accompanying an icon button is that it should be on a single line. If it ran across multiple lines and then was translated to a language which used longer words for the translation then the translated text would not fit in the available space.
You should only use text that can fit on a single line.
For your examples above, I'd recommend "catalog" and "downloads" as labels for the two buttons on the right.
It looks like there some regional dependency and there is no fix yet, since it not accessible from the application. Same problem at the msdn.
Users reported: English-UK, French, German or Dutch - wrap. English-US - truncate.
Icon button text is displayed beneath the icon when the user expands the application bar.
If the length of the string exceeds 7 to 13 characters, depending on the width of the characters
that make up the string, it is clipped.
Menu item text does not wrap and should be limited to 14 to 20 characters in length,
depending on the width of the characters.
Many languages use different amounts of space to convey the same meaning. Therefore,
when choosing menu item or button text, consider the different lengths of the text strings
for the language your app will be in. Assume that an average of 30% more space will be
required for any text. Depending on the language and the phrase, the localized string
might even require twice as much space.
The TortoiseHg Commit window has a thin vertical red line in the text area where you can write your commit message:
What is the purpose and/or meaning of this line? The relevant TortoiseHg documentation comes up empty. Searching Google and Stack Overflow currently give zero results.
Is it a suggested(?) or recommended(?) place to put hard line breaks in commit messages? If so: why have such a suggestion at all, and why at that particular location?
Okay, bro, it 's your personal hand-made settings (default value - unspecified)!!!
TortoiseHG - Settings - Commit
and at the bottom, when this listbox is active, you can read description and purpose of this parameter
Without knowing this platform I would say it's a text wrap marker - where text would wrap when printed as pure text to a printer. the old "standard" had a width of 80 chars (72 on some platforms) for ASCII-based documents.
The width was also relevant to pure-text document viewers who typically wrapped text at 72 or 80 chars. It was also used for terminals at the time when BBS'es was the norm (before internet became popular).
I suspect the reason is to provide backward-compatibility to the more old-school developers who might want to read this in a plain text reader and for printing (printing pure text is many times faster than formatted text which is printed as graphics, and therefor convenient when printing documentation and so forth). But this will be just a guess on my part.
I'm writing a generator for training images for Tesseract OCR.
When generating a training image for a new font for Tesseract OCR, what are the best values for:
The DPI
The font size in points
Should the font be anti-aliased or not
Should the bounding boxes fit snugly: , or not:
The 2th question is somehow answered here: http://code.google.com/p/tesseract-ocr/wiki/TrainingTesseract3#Generate_Training_Images
There is no need to train with multiple sizes. 10 point will do. (An exception to this is very small text. If you want to recognize text with an x-height smaller than about 15 pixels, you should either train it specifically or scale your images before trying to recognize them.)
Questions 1 and 3: by experience, I've successfully used 300 dpi images/non anti-aliased fonts. More specifically, I have used the following convert parameters on a training pdf, which generated a satisfactory image:
convert -density 300 -depth 8 [input].pdf -background white -flatten +matte -compress none -monochrome [output].tif
But then I tried to add a dotted font to Tesseract and it only detected characters properly when I used a 150 dpi image. So, I don't think there's a general solution, it depends on the kind of fonts you're trying to add.
I found the answer to the 4th question - "Should the bounding boxes fit snugly".
It seems that fitting the rectangles as much as possible gives much better results.
For the other 12 pts and 300 dpi will be good enough, as #Yaroslav suggested. I think anti-aliasing is better turned off.
Good tool for tesseract training http://vietocr.sourceforge.net/training.html
It is good tool because having number of advantages
bounding box on letter can be editable by GUI based interface
automatically create all require file
automatically combined all files like freq-dawg, word-dawg, user-words (can be empty file), Inttemp, Normproto, Pffmtable, Unicharset, DangAmbigs (can be empty file), shapetable into single eng.traineddata file.
New training data can be used with existing tesseract file end.traineddata