I simple wanted to know how many characters can be viewed without overflow (horizontal scrolling) on any GitHub source view page.
On OS X v10.9 (Mavericks):
Google Chrome: 125
Firefox: 122
Safari: 121
I attempted to simulate the font-family fall back with the web inspector
On Ubuntu:
Firefox: 126
Opera 12.16: 126
Chromium: 113
I was just testing this again https://github.com/aizatto/character-length
Testing on macOS Sierra 10.12.6 (16G29):
For both:
Safari Version 11.0 (12604.1.38.1.7)
Chrome Version 60.0.3112.113 (Official Build) (64-bit):
When:
Viewing a file (Fixed Length): 117 chars
Viewing a diff (Scales):
920px width - Half of MBPr 15"; Usable but requires scrolling: 58 chars
1280px width - 3/4s of MBPr 5"; 1/2 of 2880px; Decent: 78 chars
1706px width - 3/4s of 2560px: 115 chars
1920px width - MBPr 15": 120 chars
2560px width: 164 chars
With the new GitHub design, 160 characters are visible for me on Ubuntu - Chrome or Firefox.
1280×1024 users will initially see 158 characters if they have a vertical scrollbar, though by scrolling a little horizontally they can still view 160 characters with up to 4 digits of line numbers.
So basically 160 characters is now fairly safe for desktop users. Mobile users are pretty much a lost cause - 37 characters for devices 360 CSS pixels wide.
Thanks to #aizatto for the link to https://github.com/aizatto/character-length.
Related
Why when i check on report the stretch with overflow property the textfield adds an extra space?
i have this configuration on it:
the textfield has a height = 12 px
the width is the same of the page (572 px)
the font size = 10 px
In his image each line is a field, and doesn't contains line breaks except line 4,jasper adds one spaces after line 1 and 3 and additional for line 4. Here is the problem:
I compile my reports on windows and doesn't happen when i generate the report on windows, but this occurs on linux
the solution which worked for me.
Create a new jasperfonts jar from ireport,
Add a spring.jar file and
Set the fonts to Arial
Make sure it runs ok in AIX.
I am trying to delete a file from the first blank line to the end of a .txt file. I am using the following line of code:
sed -i -b '/^$/,$d'
(taken almost directly from Unix Power Tools). In a multi-page document, this successfully deletes the second page of text, but still leaves the footer on the first page(see below *text slightly modified for space):
29 0235600 Drain Pan
62 6151060 Nut, Serrated 5/16-18 Hex
7003932
30 6201920 Screw, 8-15X2 6-Lobe PH
W/H Network Svce
63
64 7003931 W/H Network Svce
4
# 1 - Revision D - February, 2007
375844
Previous Page Main Menu Model 648PRO Menu Next Page
I am using GNU sed version 4.2.1
Any suggestions please.
Those things at the end (CR/LF) are DOS style end-of-line characters. I don't know why the -b option isn't coping with them, but you can try this kludge:
sed -i '/^.$/,$d'
I'm using TinyMCE in Right-to-left mode. sometime i need to right an specific word or text with Left-to-right direction inside a paragraph or a long sentences.
A common example is writing a phone number inside a text:
لطفا با شماره تلفن +1 818 574 3696 تماس بگیرید
Is this example only phone number should be Left-to-right to be shown correctly as +1 818 574 3696.
I'm wonder if there is way to do that in TinyMCE without editing the HTML code manually.
First, PLEASE PLEASE PLEASE - this is not a religious discussion about editors. I just want a How To sort of answer.
That said, in editors where the data is seen as a matrix (sometimes called Eastern Orthodox Editors, examples: SlickEdit, Xedit, E/PM and the switch+alt+A block mode in eclipse) rather than a long string broken into rows (Western Orthodox Editors) it is possible to have a function, usually called "ALL" that takes a search argument and shows only ALL the lines containing that search. So if you had a file like:
11 22 33 44 55
22 33 44 55 66
33 44 55 66 77
77 88 99 00 11
and issued an ALL for "11", you'd see only the lines with 11 in them:
11 22 33 44 55
77 88 99 00 11
The other lines would be hidden and, most importantly, any edits applied would only act on the visible lines, not on the hidden one(s).
So, it there a tool, add-on, built-in, whatever, that will do this for Eclipse? And for that matter MS/VS and NetBeans?
Thanks!
I don't know of such an editor function, but you can do a file search specifying the string and the search view will give you a list of the lines containing the string. It's just that the list is displayed as a tree and not a solid block of text.
I'm running the indigo release on Windows Vista.
I have set both the print margin in General -> Editors -> Text Editors and the maximum line width in Java -> Code Style -> Formatter to 100 characters, yet it is still determined to wrap my comments at column 80.
For example, when this is typed at the top of my file:
(longest lines are 90 and 94 characters respectively)
// This comment is over 80 characters long, but it is in no way over 100 characters long.
/*
* The same problem occurs in block comments as well. True, neither problem is code breaking,
* but it certainly is annoying all the same.
*/
It is formatted to:
(lines are 73 and 79 characters respectively)
// This comment is over 80 characters long, but it is in no way over 100
// characters long.
/*
* The same problem occurs in block comments as well. True, neither problem is
* code breaking,
* but it certainly is annoying all the same.
*/
I have tried restarting Java and have hit every "apply" button I can find, but to no avail. It does not appear to be listed as a known issue in the release notes. Is there something I'm missing? Something simple perhaps?
At least on Eclipse Helios (3.6), there's a separate "Comments"-tab on the Formatter-settings, which has its own "Maximum line width for comments"-setting.