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.
Related
I am using tesseract 3.05 for reasons beyond my control. I am using source files to train the engine to detect this unique font. As I have a vast amount of samples, I am simply using the samples themselves as the training images rather than segment them into a font training image as this should give it more variation and training with the specific spacing issues this font has.
My question when generating the box files, as some letters are touching at corners (i.e . no clear break between glyphs), it will detect them as one glyph instead of two separate glyphs. An example it sometimes struggles with NA as the front serif of the A has bled into serif of the N. The image pre-processing I have applied has improved it by leaps and bounds but there are still some that I cannot correct on the image enough.
My question is this: can I simply denote the glyph as being NA in the box file?
If I cannot what would be the simplest solution? Introducing another glyph box seems like it wouldn't be a good idea but the only other solution I can see is to manually edit the image to make the separation of glyphs more obvious. This is itself anthi-thetical however as this is the kind of problem the font will have in the future that I am trying to OCR.
Thank you in advance but the documentation isn't specific on if I can correct a box glyph to being two characters instead of just one (or I just haven't found a relevant section where they explain this).
After scouring the documentation, I managed to find a lone paragraph that wasn't appearing in my website scraping:
"If you didn't successfully space out the characters on the training image, some may have been joined into a single box. In this case, you can either remake the images with better spacing and start again, or if the pair is common, put both characters at the start of the line, leaving the bounding box to represent them both. (As of 3.00, there is a limit of 24 bytes for the description of a "character". This will allow you between 6 and 24 unicodes to describe the character, depending on where your codes sit in the unicode set. If anyone hits this limit, please file an issue describing your situation.)"
Thus you can do what I ask: represent a glyph with two or more characters in a box file for Tesseract.
Some of the pages on the site I'm building cause chrome to prompt simplified view when viewed on mobile. These pages specifically seem to be the ones with more content (just more text and images than the others). Simplified view spoils the website look so ideally none of the pages would prompt this but I can't find a list of what could be causing the prompt in order to deal with it.
As a guess it may be possible that there is a word count above which the prompt loads or perhaps the greater amount of content is a red herring and there's another cause.
I found this Stack Overflow solution but unfortunately my text size was already larger than the answer recommended and so wasn't of help in this case:
Prevent show simplified view prompt or work with simplified view on Chrome
Thanks in advance for any assistance on this
I have experimented with the total word count, number of images, number of 'p' elements and length of page. The prompt is incurred if there are more than a certain number of text elements but that those elements each have to have a minimum amount of text.
Pages with few elements containing large volumes of text do not cause the prompt but neither do pages with many elements with little text, only pages with a certain number of elements with no less than a certain number of words cause the prompt to appear.
This seems to be the problem with the pages at fault on my site. Since I didn't want to change the volume of text on the pages I instead replaced the elements with elements which solved the problem, definitely not the most proper way to do it though.
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)?
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 looking for a feature somewhat like the vertical red 80 columns marker in NetBeans but one that's easier to use. I'd like it to function more like the tabs in MS Word except that the horizontal line is displayed on the entire file. I looked on the Comparison of Text Editors over at Wikipedia and I didn't find that "vertical ruler" was one of their features.
It would be used to line up html tags in a massive file that I did not create, but have to maintain.
The Zeus editor has the option to set two vertical column markers. The first is the line wrap column and the second is the left margin column and the settings for both of these markers are found in the document type.
These markers are drawn as a solid vertical line one pixel in width.
Notepad++ has this feature.
At http://tech.groups.yahoo.com/group/vim/message/87027?l=1 is a way to get a similar behavior in vim.
You can do column guides in Visual Studio: blog post here (registry entry required though).