Today I've decided to learn about writing LaTeX posters. I want to ask if tcolorbox is the right place to focus my effort in creating poster sections.
Here's why I'm asking. The first thing I tried was the package fancybox and the shadowbox environment. As long as I had white background, that looked nice. However, when I changed the background color of the poster and I came to realize that the background color of a shadowbox object is not customizable. In the a0poster document class, at least, that was my experience. When I set background in blue
\usepackage{color}
\definecolor{page_backgroundcolor}{rgb}{0.0234375, 0.339844, 0.710938}
\pagecolor{page_backgroundcolor}
the background within the shadowbox was blue. It seems not possible to adjust background color.
\shadowbox{\parbox[c][5cm]{0.98\columnwidth}{%
\begin{center}
Some box content here
\par\end{center}%
}}
\par
Then I started looking for alternative box packages.
Staying with a0poster examples, I found tcolorbox. This has more parameters, seems to be fine in a0poster documents. I tested on a beamer poster and the results are also GOOD. Downright surprising, actually. It usually seems to me that beamer contradicts special-purpose packages.
The beamer package has its own block environment, but I find that harder to adjust to taste than tcolorbox in a beamer document.
I want you to tell me if I'm just having beginners luck. Or should I focus on some other box package. When I needed to do color within tables last year, I found there were quite a few problems in adjusting colors in cells and lines and if I'm going to run into that with tcolorbox, you could warn me now.
I also have experimented with tikzposter which offers its own very elaborate system for creating boxes, but I'm not pursuing that right now because it appears to be very specialized (not portable) work. Correct?
If tcolorbox is the right place to focus, let me know. If not, what should I study.
There seems to be no clear question, that makes a clear answer hard, but a few comments to the things you mention in the text:
tcolorbox is usually safe to use with beamer
\usepackage{color} is not necessary if you use the beamer document class, it already loads xcolor
Instead of setting the page colour with
\pagecolor{page_backgroundcolor}
I suggest to use the beamer way of doing this and use
\setbeamercolor{background canvas}{bg=page_backgroundcolor}
I would stay well away from tikzposter, it tempts its users to nest tikzpictures, which should better be avoided. Also it nests tikzpictures itself if innerblocks are used.
I'm experiencing painting issues when combining TScaledLayout and custom styles created from the bitmap style designer in fmx.
To demonstrate, I loaded the default custom style created by chosing "New style for VCL / FMX" -> "save as .style" in the bitmap style designer. I dropped several standard controls on some colored rectangles: The red & green ones on a TScaledLayout, the blue one directly on the form. As I stretch the form, colored lines appear on the controls on the ScaledLayout; the background is partially visible:
If I size the form to exactly match the design-time dimensions, the lines disappear. That seems like a pretty significant issue, I certainly can't use those two together like that. Does anybody have an idea for a possible fix or workaround?
Looks like this is a known issue with scaling and bitmaps. See the Google+ discussion here - https://plus.google.com/+PaulThornton/posts/ACAHkJD3a84. I'll quote Marco Cantu's thoughts:
I've found an internally reported issue of a similar case, but haven't
found one that matches this scenario. Certainly worth adding to quality
portal. Having said this, I fear that bitmap-based operations and
scaling don't really fit together very well, and it might be difficult
to have an all encompassing solution.
Let me explain with an example. Take a button. This is painted by FMX
with 9 sections (borders, corners, central part) so that regardless of
the size the bitmap elements are stretched in one direction at most,
often just draw. Stretching a single bitmap for the button to the
target size would break anti-aliasing and create a blurred image when
using colors.
This is example what happens with a ScaledLayout, given it takes the
complete final image and transforms it. ScaledLayout was originally
introduced with vector styles, and worked very well in that scenario.
With todays's bitmap styles things get a bit more complex.
Regardless of this explanation of there the issue lies, I'd recommend
reporting it on QC, and I'll make sure it doesn't get closed as design
(it could naturally happen, this is how the system works) but that we
do some investigation to address the issue -- turning this into a
feature request.
We were using Delphi 2010 with the full VCL edition of TeeChart this worked fine
We have now updated to Delphi XE 5 with the latest version of TeeChart and the quality of the charts is now worse
Please see the image here
2 bars which were seperate are now merged into 1 bar
If I make the charts wider which is not an option it looks better but still not as good as before
Please see here
Has anyone come across any issue like this?
The projects are here for Delphi XE5 and here for Delphi 2010
The search paths may need modifying
Cheers
Paul
The issue might be because of the anti-aliasing function being turned on by default in the newer versions of TChart(!).
We had the same issue with a line series graph.
After writing to the vendor (Steema) they came up with the following solution:
Chart1.Canvas := TTeeCanvas3D.Create; //Disable GDI+ to prevent smooth drawing of the graph.
I don't get why we have to switch off drawing with GDI+ as - to my knowledge - GDI+ can also be used without anti-alias.
Anyway, our graphs now behave like the previous versions of the TChart, which is what we want.
I was also hating the "new" anti-aliased charts that are blurry and slow.
It's pretty easy to fix, when you know where to search for.
Double-click on chart, then go to 3D -> Render -> select GDI instead of GDI+
If you look "behind the scenes" into DFM file you can see the change:
Crisp and fast graph (as in 2010): DefaultCanvas = 'TTeeCanvas3D'
Blurry and slow graph (as in XE5): DefaultCanvas = 'TGDIPlusCanvas'
chart settings
Hope this helps.
Some kind of a clumsy runtime workaround was found here, that is also working:
http://www.teechart.net/support/viewtopic.php?f=3&t=15078
TdxComponentPrinter is a componenet that allow me print a TPanel on a paper. But there is problem and when the panel contains TImage, the background of the image will be converted to black in the paper.
Before print :
After print (on the paper) :
I have tried different ways to solve this problem. for example i used Repaint; method of TPanel,...
but doesn't work and the background of image is still black. I don't know why!!!
Help me please.
This is a png file, which might not be supported completely in your Delphi version. Did you try to change it to a TcxImage which might be more compatible with the DevExpress printing system?
It also might be worth it to submit this issue to DevExpress if you can't fix it. They reply really quick and know more about their components then all of use here on SO :-)
If it is already a jpg then you should improve the quality of the jpg. It looks like the black parts are compression artifacts where there is a mix between white and another color. If you clean up the background of the image with a paint program it will probably look a lot better.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 months ago.
Improve this question
Does anyone program with white text against black background? I have heard some rumors that it is better for your eyes. What's the case? Is it any better than the traditional black on white? What are the pros and cons?
It's actually white on black, or rather green or amber on black, that is the traditional way. I've used them all. :)
I believe that the use of black on white started in word processors, because it's a lot easier on your eyes when you alternate between looking at the screen and looking at source material printed on paper.
Also, the contrast between the screen background and the surrounding lighting should be small, so a white background works best with the well lit room most people use computers in most of the time. If you are programming in the darkness a black background would give less contrast, but then it's more a question of why you don't have proper lighting in your room...
There are of course personal preferences than can affect your choise of color setting, and your eyesight (or lack thereof) might also make one setting better than the other.
There is an endless debate on slashdot one can go through for all the unintelligible technical details (the more technical analyses seems to favour dark on light side though).
This article, though about web designing, warns about the hazards of mindless black theming. The important aspect I understand is that the font is more important than coloring schemes. There is also disadvantage for black (not dark in general, but just pure black) background with white font if font is thin, since black creeps on to white and font would look a lil' blurry.
Despite all that, personally I find reading on darker background much easier for eyes. I don't think there is a definite answer for "light font on darker background" or vice versa. It will have to depend on personal tastes and habits more importantly. For sure, the right scheme lets the font (the writing) to project to fore and subdues the background. Now ask yourself is it dark on light that does this or light on dark? Here is the key, in that advocates who vouch for similarity with print suggesting that black outshines the white on paper, is blind to the fact that it is not the situation when it comes to electronic screen. Here the intensity of white beams on your eyes is much higher when compared to black.
And there is nothing like a best background color or fore color, but its the combination that matters. Right combination gives the right contrast, and contrast matters. And contrast should be sufficiently high, but not enough to be straining. Pure white on deep black can be hurting (the contrast being significantly high) but at the same time white on dark green is soothing. The same goes with amber on black.
Also when having a dark background it should be pale and not intense, so something like dark grey or teal will be better than black which in turn will be better than blue, red etc. Black on grey is excellent.
The solarized theme actually is after some good round of testing, going after their website. The good thing I love about Notepad++ is that some of the better known themes like solarized, zenburn, vibrant ink are available built in with the style configurator. Obsidian is the best without a doubt btw! :) Catch it for Visual Studio here.
It seems to be a preference thing and possible environmental thing, honestly. You'll find people who believe each method is superior.
I know that personally, I have coded since the green-on-black and amber-on-black terminals were around, and now I use light gray text on black backgrounds wherever possible. I find black backgrounds to be extremely comfortable on my eyes even for very long sessions, but white backgrounds are very fatiguing. I have heard it described as "staring into a 100 watt lightbulb" and that's how it feels to me.
Room lighting can potentially have a significant effect also. Brighter rooms may lend themselves to brighter backgrounds, and darker rooms to dark backgrounds. It reduces the need for your eyes to struggle to switch between wide and narrow pupils required for bright then dark then bright as you occasionally look away from the monitor to relax your eyes (you should always do this, right?).
The best advice is to just try both, give it a week or so, and decide which you like better. If you find both the extremes are glaring, try using a more subdued theme than pure whites and pure blacks, try some softer grays.
The quick answer is "dark text on white background suits more people".
My answer refers to this one: https://graphicdesign.stackexchange.com/questions/15142/which-is-easier-on-the-eyes-dark-on-light-or-light-on-dark
As a person with astigmatism, I find white background with dark text is easier to read as the reference suggested. (I specifically experienced this after using the dark theme in visual studio 2013. It is so fuzzy to me that I had to change back to its 2012 default theme.)
Below are the quotes:
The science of readability is by no means new, and some of the best research comes from advertising works in the early 80s. This information is still relevant today.
First up is this quote from a paper titled “Improving the legibility of visual display units through contrast reversal”. In present time we think of contrast reversal meaning black-on-white, but remember this paper is from 1980 when VDUs (monitors) where green-on-black. This paper formed part of the research that drove the push for this to change to the screen formats we use today.
However, most studies have shown that dark characters on a light background are superior to light characters on a dark background (when the refresh rate is fairly high). For example, Bauer and Cavonius (1980) found that participants were 26% more accurate in reading text when they read it with dark characters on a light background.
Reference: Bauer, D., & Cavonius, C., R. (1980). Improving the
legibility of visual display units through contrast reversal. In E.
Grandjean, E. Vigliani (Eds.), Ergonomic Aspects of Visual Display
Terminals (pp. 137-142). London: Taylor & Francis Ok, 26% improvement
– but why?
People with astigmatism (aproximately 50% of the population) find it
harder to read white text on black than black text on white. Part of
this has to do with light levels: with a bright display (white
background) the iris closes a bit more, decreasing the effect of the
"deformed" lens; with a dark display (black background) the iris opens
to receive more light and the deformation of the lens creates a much
fuzzier focus at the eye.
Jason Harrison – Post Doctoral Fellow, Imager Lab Manager – Sensory
Perception and Interaction Research Group, University of British
Columbia The "fuzzing” effect that Jason refers to is known as
halation.
It might feel strange pushing your primary design goals based on the vision impaired, but when 50% of the population of have this “impairment” it’s actually closer to being the norm than an impairment.
The web is rife with research on the topic, but I think these two quotes provide a succinct justification for why light text on a dark background is a bad idea.
I'm sure that plus of programming and using white on black layouts causes less energy using.
Example of site saving energy by black layout is http://blackle.com/
well if you are programming when it is already dark outside then yes that rumor might be true becuase it is better for your eyes if the contrast between your monitor and room is smaller.
Below mixed with my own thoughts and others.
Pure Black:
Pure white text on pure black is awful for reading (it's looks awesome on some graphs). Contrast is too high, and pure black may looks unnatural. So Visual Studio is using dark grey, just like Photoshop.
Visual Studio Team Says:
According to The Visual Studio Blog, dark editor themes are overall more preferred, reduced strain over long time usage is the top reason.
Emotional Expectation:
Emotionally, at least for some I guess: things related to creation with a dark theme may feels better, like those software; things books alike, e.g. blog or something, light background may better, since it's more expected.
Black for Colors:
For eyes, generally, I'm fine for both light and dark theme, since I'll always make sure the backlit not too light. As for Visual Studio, I guess the strain for eyes comes from the scanning of colors. You know, it's already hard to recognize all those colors (okay not that hard, you got the point), then there's that big fat white on the way, all the way. Guess eyes just have a "color sensitive mode", like people may not enjoy two white bars even if it's a light colored cartoon.
Light background easily makes things look clean, leads to higher readability for articles; dark background helps emphasize the color, leads to higher readability for codes.
One difference between blog and code text is that, codes are generally colored in a way it can standout its construction. Read an article will focused more on its meaning behind the words, but reading codes focus more on its visual construction and color, focus more on words itself. In photo editing and movie playing, dark colors provides less distraction. We treat codes actually more like a photo or video where visual matters more or even lots. Dark background fades away and makes the visual construction stand out.
I use black background, because it wont strain my eyes. I used to regularly use white background, After 2 years, my eyes started getting strain. i tried to reduce the screen brightness, but it didn't help.
Finally i switched to black and now my eyes hardly even get stressed or watery (but still i'm going to wear spects soon)...
I know this is an old question, but I figured I'd give a little bit of my input. Maybe it'll help someone.
Purely white background was starting to hurt my eyes from several hours of nonstop programming. My vision was getting blurry to the point where I would have to stop. I attempted to use darker themes, but it was harder to focus on text and that made it more difficult for me to scan through the code to find a particular bit. Search functionality would not always work, because I might not know what I'm looking for (solving an exception-less bug, etc).
I looked around and found out that some gamers and programmers use yellow-tinted glasses. Popular choice appears to be Gunnars. However, I didn't feel like spending $70 on a pair of glasses, because historically, my comfort zone with glasses is very narrow and I didn't feel like wasting my time or money.
So, further searching around brought me to f.lux. It's absolutely free. The default settings were a bit too extreme for me and I couldn't get used to them even after two weeks. However, after adjusting them slightly, I've been enjoying it very much. During the day time, the screen is at its normal tone and intensity, but as the evening closes, it transitions into dimmer settings. When I tried to test the difference (after getting used to it) by disabling it, it made it painful to look at the normal screen. So, it does work. If you decide to give it a try... just try to use it for a few weeks before dismissing it. It took me a while to get used to it.
Anyways, if you just can't stand darker themes, like me, those two options are probably a good way to remedy that issue.
I have heard that black text on white background will not hurt your eyes, but using a black background for a long time, can make visual problems of your eyes.
B.K. brings up a lot of points that I too experience. First of which I know this is an older post, but it's still a relevant question. Secondly where I differ is I use a hybrid of darker and traditional lighter themes.
Personally I find darker background to be visually better. When I code I use this type of theme in my IDE Dark Theme for Visual Studio 2010 With Productivity Power Tools. The one thing that I do differently is I do not use the very dark code area or alter the coloring of the text. I go in and change my Options > Environment > Fonts and Colors > Plain Text > Item Background > Custom > Silver. This in turn gives me the aesthetically pleasing darker menus and such in the IDE but still makes my eyes focus on the code. It also keeps all the text and color coding that is native to the default IDE. This of course is for Visual Studio 2010. Newer versions or different IDEs have their own themes.
I have very light sensitive eyes and I tend to get headaches when coding all day without breaks. So I prefer toning the menus, tool bars, and side bars of an IDE to be darker. I also do use the Gunnar glasses.
There's quite a bit of evidence supporting that white background with darker text is actually better for your eyes in well lit office situations and such. https://ux.stackexchange.com/questions/53264/dark-or-white-color-theme-is-better-for-the-eyes Has some very good sources listed throughout the responses on these studies. This is mainly concerning design for end users, but at the end of the day even though we are developers we are still end users of the IDE products and the same rules still apply.
So in conclusion it has a lot to do with your environment, your eyesight, and what you prefer. I personally use a dark IDE with a gray or silver work space with traditionally dark text. This makes it still easy to spot the contrast, but doesn't hurt my eyes by overwhelming me with white.
On my laptop dark background create too much light reflection.
It is really cool for your eyes.
White means full colour -- rgb(255, 255, 255) -- and black means no colour -- rgb(0, 0, 0). So when you are reading some black text against white background, the screen is flashing a lot of light except for a small portion (the text). On the other hand, when you are reading a white text against black background, the screen emits (almost) nothing except for the text area. That's why it looks so cool.
However, the contrast and environment lighting matter. Although I prefer white on black, both pure white on pure black and pure black on pure white have a high contrast, making things unreadable. In my personal experience, 'dark white' text on 'light black' would be the most suitable and long-readable theme for any environment.
I used to program with
White background, I felt more tired and kind of flickering when going home and more tired.
Then I switched to Black background
Eye feels more relaxed and much less tiring and stressed.
I am not sure, which is good for eyes though.
Technically.
When the background is Black the iris open more. I think it allows more radiation in. Not sure.
I'm using white background, because as a web developer you moving from browser to editor all the time and most websites are in white.
I tried to use black background and my eyes started to hurt, because of the switching between both editor and browser. (editor - black, browser - white)
I guess if you work just in black background for all your apps this might work