Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
I use i3 as a wm, so when I switch terminal size, all text remains same position as it was on previous size.
For example this happens when I start man man and then go full screen.
Also it's huge pain when try to do something continous like pip install --upgrade pip it prints new response on each line instead refreshing.
That's what happend when I toggle fullscreen:
It is generally not possible for terminals to reformat already printed output when re-sizing, other than wrapping lines that are too long. Especially not in a way so that the output looks like it would have if the terminal had had the new to begin with (stretching/shrinking old progress bars, reorganizing the columns of outputs from ls, etc.). The information that would be necessary for that is just not available to the terminal.
The content of a terminal is essentially just a sequence of characters that are printed from left to right, from top to bottom. New lines happen by explicit newline character (\n) or when writing more than what fits in a line.
There is no formatting option for right, center or justified alignment. Anything that looks like it is doing one of these alignments, is done by the program producing the output (usually by taking the current terminal width and then either by placing the cursor at the appropriate places or just by printing a line that goes the full width of the terminal). One your second screenshot you can see how pacman prints the current progress bars depending on the current width of the terminal. You can also see how it will shorten some names in order to have enough room for the size and speed informations. The missing part cannot be restored by the terminal emulator and pacman (and most other programs) does not go back in the terminal buffer to modify their previous output to fit a new window size. Usually progams just add new output at the bottom. Progress bars are often (most of the time? always?) done by going to the beginning of the current line (printing the special character \b does that) and overwriting the line with updated information, again and again.
Of course there are some programs that actually can (or successfully pretend that they can) handle window re-sizing for all of their output. These programs usually take over the whole terminal window (vim, less, elinks, ...) and reformat their output on their own as required. If they have the required information, that is. In your first screenshot less does not have the necessary information to reformat the text.
Related
I have build some algorithm and now I should make things pretty enough for presentation. Only problem what I have is a "strange" legend behaviour in octave. I dont know if the problem is because I am using "subplot" function, but I have tried several ideas what was possible to find on google, but none of that really works.
At the uploaded picture we can see that diagram lines names are moved all the way to the left (nothing wrong with that), however there is too much space on the right side of the line names. The legend box is simply too big for the context inside. I have tried already with reducing the size of the font, but is not the best solution.
Can somebody please provide some solution for my problem. My current code status is:
hleg1 = legend({"sample1", "sample2", "sample3"});
set(hleg1, "FontSize", 8);
I currently using Octave version 5.1.0 on windows 10 x64.
The fix for me was te execute the plotting script twice.
The first time you resize the window in full screen mode.
Then you execute the script again (without closing the figure window)
Now legends should not take half the space of your plot ;)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 6 years ago.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Improve this question
Not a Wordpress expert, but reasonably well versed in HTTP/HTML/CSS/Javascript/etc. Customer has a Wordpress site of not recent vintage, and I want to just get in, do the minimal required work, and get out. A page needs an image, so I upload it to the "Media Library". Push buttons and doodads to insert it into page, view the result and... the image looks blurry.
Some hours later, I understand there's a ton of Q&A about blurry images on Wordpress, but AFAICT they have nothing to do with my problem. When I view the image in a browser, it is reliably being scaled up by precisely 4/3 (1.33333...).
What drives me nuts is, I pick a browser, load the page, go into the console debugger, and it agrees both that the image is being rendered at 4/3, but also knows exactly what the correct original size is. Fine, but I should be able to see why it is rendering at 4/3. I cannot locate any relevant CSS parameter that is causing this. I have tinkered with enumerable combinations, including elaborations where I shove the img in a div and set the width of that div, etc. Every single time, the browser calmly scales the image up. In Firefox's console debugger, the "box model" view displays the actual original size rather than the scaled-up blurry size.
I feel I have eliminated PHP and Wordpress by just using Ctrl-U or the browser debugger to look at the result. But apparently somebody has managed a trick I don't understand, so I'm not sure whether to view this as a Wordpress question, CSS question, or what. So I'm flinging this question out in case the magic scale factor of 4/3 rings a bell with someone who immediately knows what the problem is. Let me know if other info is required to locate the problem.
I just checked it in IE11 on a virtual machine running Win10 and it was the correct size. It may sound daft, but are you sure you haven't accidentally enabled zooming in your browser?
This might sound simple-stupid, but sometimes, we all tend to miss something trivial:
While inserting the image/s into page, there is a column called ATTACHMENT DETAILS (extreme right). Down below on this column, there is a Size dropdown. Have you tried adjusting that? HTH.
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.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
In my University tests I often have to write programs and algorithms with pen and paper. For example, for my next test I'm going to have to write quite a lot of code in scheme and Java on paper.
I write quite a lot of code, but never on pen and paper. When writing code on paper, I often go at it with the same attitude as if I'd be writing the code on a computer. This often results in a lot of strikethroughs and additions, which often results in a total incomprehensible mess, because I'm used to being able to add and remove blocks as I please.
The problem is the programs or algorithms are complex enough so that it's not possible to think them completely through in your head before writing the code.
Is there any way to effectively and efficiently write code with pen and paper?
You are right in writing the code on paper as you write it on the system. But, to write an efficient code, you need to learn few things
Always use indentation at every line of code to make it presentable
Don't forget to add comments at various points so that what you are writing and trying to convey gets clear to the examiner
If anywhere you want to cut through some parts of your code, or encounter a strikethrough, better strike out the whole line and rewrite it. It improves the visibility of the code and makes it appealing.
Remember to leave ample amount of space between two lines of codes, probably a blank line or two. This spacing makes your code presentable.
More suggestions are welcome.
Ugh... Programming on paper!! =(
When I am backed into a corner and forced to do this, I like to have a pad of scrap paper handy. I nut out the shape of the program on my scrap paper.. That means I draw a bunch of rectangles, roughly representing how much code I might have to write in a block. When I realise I need something else in between, I sketch more rectangles and draw obvious arrows.
A rectangle might say a few hasty words about what it's achieving, like load stuff from thing. Or x < y ? Or whatever helps me get a feel for what I think I'm going to write, without wasting too much time. I might also note down variable names I intend to use further down, and draw an arrows to where that may be... Or even write a line of code that I mustn't forget!
That means I already have an overview of what I'm doing before I start the code. It gives me time to sit back and make sure I have thought it through. Then I can focus on implementing small chunks at a time and keep my thinking more linear. That's useful because I make more mistakes if I'm thinking ahead at the same time as writing.
Works for me... Might be useful to you, or it might just sound like rubbish.
I need to extract/crop the logotype (BEAVER) in the middle from a TIFF file that looks like this: http://i41.tinypic.com/2i7rbie.jpg
And then I need to automate the process so it can be repeated about 9 million times...
My guess is that I would have to use some OCR software. But is it possible for such a software to "crop anything that starts below this point and ends above this point"?
Thoughts?
Typically OCR software does only extraction of text from images and conversion of it into some text-specific format. It does not do crop. However, you can use OCR technologies to achieve your task. I would recommend following:
OCR whole page
Get coordinates of recognized text
Apply your magic rules to recognized text to locate area to crop: such as averything in between "application filled" and "STATEMENT" sentences.
Cut from image that area and export it where you want it.
Real challenge is in the amount of text you would like to process. You have to be very carefull when defining your "smart rules" to make sure they don't provide false positives and always send suspicious images to separate queue that you will later manually review and update your rules.
In general it may look like this:
Take first 10 of images, define logo detection rules, test and see if everything works well
Then run on next 10, see what was prcessed wrong, what was not processed, update rules, re-process those 10 to make sure everything works well now
Re-run it on new batches of same size until it will start working well.
Then increase batch size from 10 to 100, and go with those batches until again everything start working smoothly
Then continue this way perfecting your rules and increasing batch size. At some point of time you will go to production speed.
Most likely you will encounter some strange images that either contradict existing rules, or just wrong. Not always you have to update your rules to accomodate it. It may happen that there it only dozen of images like that in whole your 9 million collection. It might be better to leave them in exceptions queue for manual processing, and don't risk stability of your magic rules.