I am working on a label printing app in Electron and seeing strange behavior on elements that are rotated -90 degrees. The behavior is the same in Chrome's Print Preview window:
Rendered html on left, print preview on right (Sorry, I can't embed images)
You can see all of the barcode fields, as well as the firstname, lastname, children, pager fields are being rendered in the Print Preview window like there is a line break before the content, making it overflow out of the parent container. Other elements with the same rotation are not rendering that way (pagerno, securitycd, datetime).
I have tried making the font size much smaller in those elements, down to like 10-12px and they still have that behavior when printing, so it doesn't actually appear to be content size related.
Edit - On further inspection, the behavior does go away once the font gets to about half the size. So in the example below, the barcode font is 23px - at 13px, it stops wrapping or inserting a new line or whatever it's doing...
The HTML on a rotated element looks like this:
<div style="left:3.535in;top:0.125in;width:0.31in;height:2.03in;">
<div style="transform-origin: left top; text-align: center; transform: rotate(-90deg); width: 2.03in; height: 0.31in; top: 2.03in; left: 0px; font-size: 23px; font-family: Code128;">
<span>barcode text</span>
</div>
</div>
The CSS looks like this:
body,div {margin:0;padding:0;font-family: arial, sans-serif;}
div {position:absolute;border:1px solid #ccc;overflow:visible;display:inline-block;}
#font-face {font-family:"Code128"; src:url("./fonts/Code128.woff2");}
*, *:before, *:after {box-sizing: border-box;}
I have tried removing the width and height from the outside div, removing the width and height from the inside/rotated div and still see the same behavior.
We have three different varieties of thermal label printers on hand with different size labels and the behavior is similar, but different in each. Meaning, rotated elements wrap like this in all of them, but some printers more than others.
I appreciate any feedback or insight and will keep an eye out here for any questions or request for further info.
Thanks!
Related
For some reason png/jpg/svg files that I put into my img tag give at some random sizes a whitespace. Here is a link with a GIF:
https://gyazo.com/0cbbe95f7c9ca4e6e504448cacd8ea2c
In the GIF im resizing the screen with Chrome its developer tools -> device toolbar. Also if I click Ipad or some other device I see a white line. Its not on all devices but only on some. If I change image or check one of my other images I have the same white line but on different devices/sizes. Why does this happen?
What I checked/tried
My image tag has the display: block;
width/height: 100%;
margin/padding: 0px; Which it could never be since the whiteline is quite random.
object-fit/background-size: cover, contain, fill, everything basicly;
overflow: hidden;
vertical align: top, bottom;
div tag around my img and div tag.
Nothing here worked.
Is it possible that Chrome its device tool thingy is just not working correcty? I have some experience with it on different projects that I had to refresh the complete toolbar or switch between device to make it look normal or to make some code I added in the tools working. In the current case it doesn't fix it but maybe there are some other known issues?
This is my code
HTML:
<img src="./images/yellow-top.png" alt="top"> <!-- Shows white space at random sizes -->
<div class="bg-yellow"> <!-- height based on its content. Around 800px in my case -->
...
</div>
<img src="./images/yellow-bottom.png" alt="bottom"> <!-- Shows white space at random sizes -->
CSS
img {
display: block;
width: 100%;
}
Why does it do this and how can I fix this?
Developer tools was zoomed in at something else then 100%. This way it shows a small whitespace below an image. Setting it back to 100% fixed it. SVG file still gives me an whitespace. This is probably something within SVG files.
I'm admittedly not a fan of CSS and I hate even more responsive layouts but I'm creating an UI with Bootstrap (version 4, for what matters) in which I have some absolutely positioned elements that aren't exactly perfectly aligned as I want, be it in different native resolutions (monitor or VGA-defined) or when simply resizing the viewport (i.e.Ctrl++).
Since I began to create this UI I'm using vh and vw units for most elements (except those related to Bootstrap Grid, of course) thinking I wouldn't have such problem and this decision worked quite well for most of scenarios.
However, until now, I was using an old and very small monitor (1366x768) and recently I (finally) acquired a 21.5" monitor (FullHD, if this matters) and these values I've defined in my CSS rules, after exhaustive testings, are now slightly mispositioned, a bit to the left or to the top. For example:
This is a UUID I use for Unique User Identification in the Application and its positioning and text sizing was defined according to the rules below:
#user-identification {
bottom: 2.05vh;
font-size: 0.64vw;
height: 4vh;
left: 3.05vw;
width: 15vw;
}
As you may have noticed, the blueish background is in fact an image and the text is absolutely positioned on top of it, so I can reuse it for different use cases.
These rules created while developing in the small monitor where enough to center the text in the box of this background image. But now, in the bigger monitor I took this screenshot, you can see that the text is aligned to the left. It may be difficult to notice, I know, but this is a crop of the bigger picture which, unfortunately, I cannot show more :(
Well, I was about to start fixing all issues based on the big screen, for example, by changing the left to 3.4vw instead, but then I realized that if for any reason someone accessing the website is under the same situation I was before, the user experience would be prejudiced.
The first solution that came to me was to use Media Queries but I don't know the values I should be using to create the rules.
Worse! Regarding the viewport resizing, Firefox goes 10% by 10% while Chrome has a wider range (25%, 33%, 50% 67%...) and other browsers may have other values. And because I'm not a specialist I don't know the values I'm looking for to create the rules.
Can anyone help me?
Although it would be awesome, it's not my intention to fit the whole UI in the viewport of, for example, an iPhone 5 (the smallest I've found on Chrome Developer Tool with 568x320). I just don't want these small icons and texts absolutely positioned to be out of place.
[EDIT]
Describe the scenario in a Fiddle proved harder than I thought, that's why I tried to avoid it. But as asked, in this one I've positioned as best as I could and it looked good in the default preview area. But just by resizing it text already goes way out of positioning.
So I made this one, specifically for the embedded version. I believe it would be better as it's close to have the editor in one window and the preview in another (browser).
However, neither of them truly reflects what I really have. although the markup is compatible, both <img> and <span> inside the <figure>, I don't have these drastic changes when resizing the viewport. I have only small mispositionings on bottom and left.
I'm probably not extracting everything I should. I've got most of the Grid where this image (or the bigger, complete version of it) is located. .box is not relevant as it's just a few lines with linear and radial gradients and some box-shadow.
The whole UI is complex and I may have left something out of these Fiddles, but at least is something visual that shows positioning going wild when resizing (and definitely in different resolutions). My apologies for that.
This is the root of the problem to my understanding. There is an increase in height of the <span> element tied to the height of viewport, so the text container which is the <span> element is increased in height at the same time that the position of it via bottom and left are adjusted using viewport width/height. Removing the height setting of your elements in css, might solve the issues that you are having. Please leave a comment below, if this is not the solution to your question, and we can work together to the solution that fits this case. Thank you.
html, body {
font-size: 1rem;
height: 100%;
}
figure {
display: flex;
position: relative;
z-index: 1;
}
img {
height: 100%;
}
span {
bottom: 3.5vh;
color: #FFF;
font-size: 1.9vw;
/* height: 4vh; No need for this line right here. */
left: 1.1vw;
position: absolute;
text-shadow: 2px 2px 0px rgba( 0, 0, 0, 0.5 );
text-transform: uppercase;
width: 37vw;
z-index: 2;
}
<figure>
<img src="http://nick.mtvnimages.com/nick/promos-thumbs/videos/spongebob-squarepants/rainbow-meme-video/spongebob-rainbow-meme-video-16x9.jpg?quality=0.60" />
<span>f51bbe1e-7445-4545-bb84-15e614a119a2</span>
</figure>
Consider the following example:
<!doctype html>
<html>
<head>
<style>
td {
padding: 0;
background: red;
}
img {
display: block;
}
</style>
</head>
<body
><table
><tr
><td
><img src="https://raw.githubusercontent.com/sinatra/sinatra/v1.4.7/lib/sinatra/images/500.png"
></td
></tr
></table
></body>
</html>
There's a red line in chrome on the right of the image. No such line in firefox. It doesn't seem like a space, because the html markup has no spaces between tags. It doesn't seem like a margin, because Developer tools doesn't report any margin.
What is this? How much space could it take?
I'm running chromium-47.0.2526.111 (64-bit), if anything.
UPD I made an example without spaces specifically to show that the red line is not caused by spaces.
Next, it was found the line appears when Zoom is, for instance, 110%. So, everything is supposedly clear now.
It is because of the way <td> elements are displayed. As you can see, they are displayed as:
display: table-cell;
This is because of how table-cell is ment to calculate pixels. Since 1 pixel is not equal to 1 pixel in CSS if you have DPI scaling enabled (or you zoom), it will start to behave weird.
You can either find another approach of your <td> inside <tr> or simply change the display to display: inline;
It's all because of how pixels sizes are calculated. I know it sounds weird, but 1px is not 1 physical pixel. Essentially what happens is your td's background changes according to the size of your image. When your image hits an odd number (because of zooming or DPI scaling), it will either round down or up. This is when the calculation happens and is wrong.
Sources: https://www.w3.org/TR/css3-values/#absolute-lengths
http://www.quirksmode.org/blog/archives/2010/04/a_pixel_is_not.html
There is no red line for me on initial load, however I can see red lines if I zoom in, which begs the question, is your browser set to zoomed in?
Look for the magnifying glass in the url bar of google chrome and make sure you're set to 100%
Causes when not zoomed
Since you have padding set to zero on your td element, that's fine, and the only thing that can make the same effect is to have the margin on the image (the margin on the child element sort of behaves like a padding on the parent element in this case). The margin could be set either by you, or by your browser's stylesheet (I don't see it on mine).
Set img {margin: 0} and it should be gone because you've covered both cases that could cause it.
Zooming problem
If you see it only when zooming, it's because of browser's sub-pixel rendering (when the pixel values become floats and the browser starts rounding or flooring them). And due to the extremely non-power-of-two dimensions of the image (313x161) it's highly likely to get that extra pixel line on various zoom levels when, say at 110% zoom, the calculated width of the td is 313.636 pixels, and the image 312.997 pixels, which become 313 and 312 when floored. That leaves us with the td element being one pixel wider than its child image, which is where the line (the red td background not being "covered" by the image) comes from.
img {width: 100%} fixes this (as Aziz already said in the comments)
This may help you:
td {
padding: 0;
background: none;
}
The correct answer is that for several years Chrome has handled images in tables defectively and no one can comprehend that this the actual problem. You have to take the images out of the table and put them in divs...
I was creating some HTML/CSS to display a key, but ended up with a weird vertical misalignment if the text for the title vs the text for the items.
After a lot of experimenting I found that the problem only seems to happen when the text is bolded, and furthermore only when using the Lucida Sans font.
You can see a demonstration of this problem here... http://jsfiddle.net/Ufa69/
HTML...
<div class="key">
<div class="t1">title:</div>
<div class="item">item</div>
<div class="item">item</div>
<div class="item">item</div>
</div>
<div class="key">
<div class="t2">title:</div>
<div class="item">item</div>
<div class="item">item</div>
<div class="item">item</div>
</div>
CSS...
body {
font-family: "Lucida Grande","Lucida Sans","Arial",sans-serif;
}
.key {
padding: 2px;
font-size: 10px;
overflow: hidden;
border: 1px solid #666666;
background: #eeeeee;
margin-bottom: 4px;
}
.t1, .t2 {
float: left;
margin-right: 4px;
}
.t2 {
font-weight: bold;
}
.item {
float: left;
margin-right: 4px;
}
In the demo you'll see that the text aligns correctly in the first div, but in the second it's misaligned. The only difference between the two is that the second one used bold.
You might be thinking, "So, use a different font".
But there's the catch - Lucida Sans is the default font for jQuery UI.
So I'm hoping that some clever CSS-guru can maybe find another way to get this text to behave correctly when bolded.
(The problem appears for me on Windows in Chrome, Firefox, and Safari, but not IE)
they are misaligned because bold and normal text allocates space differently as if bold increased font-size comparing to a normal text.
My solution here is to increase font-size to the normal text so that it will be still normal text but same size as the bolded one.see my update to your fiddle below.
.t1{
font-size:12px;
}
http://jsfiddle.net/Ufa69/1/
NOTE: there are a lot of options you can do so the bold and normal text align properly. You can use tables td's or divs with fixed widths.
Maybe I'm not good for this kind of thing. But I ain't see the misaligned issue, it really seems aligned here. (Chrome v31)
Things that happen:
To make font bold, a couple of pixels are added in font letter to do the effect.
Obviously, it gets more visible in text with small size.
Each browser, and even version, renders the font differently.
Each text, each line of text, have their font-size and the line-height. By default, line-height is auto and will squeeze to height of content. All this behavior is called, line box.
In text, with font-size: 10px, line-height will be a couple of pixels higher.
As much you will increasing line-height size, the content gets more space to go up, down, middle, etc, as defined in attribute: vertical-align
As size is added to the text, fatally it will increase line-height too.
So, I have a lot of options to do to make up this. Almost all, by changing font-size, line-height, vertical-aligns, margins.. and it's very hard to accomplish a strictly successful result.
One particularly that is often used and I like is just reduce the size of bold text in 1 or 2px.
.t2 {
font-size: 9px;
font-weight: bold;
}
You can also limit height & line-height of wrapper container to improve to leave it more equal.
See fiddle to confirm you like the result.
Nice ..
I saw that line-height differs from your .t2 (11px) and .item (14px) but even firebug doesn't mention 'why' or inheritance.
Fix line-height to 14px all around with .key{line-height:14px;}.
[edit]
After seeing it in action, i can't figure out why the line height is not inherited from .key classes elements to their children <div>
I fiddled here the same solution of 'line-height' but applied to children divs.
.key,.key div{line-height:14px;}
Some browsers apparently use odd box height calculations. This can be seen even in a simple setup like
<style>* { font-family: Lucida Sans }</style>
<p>foo<p style="font-weight: bold">foo
Inspecting this in Chrome dev tools shows the height of the first p element as 15 pixels, the height of the second p elements as 14 pixels. This makes little sense; we could expect a boldface font to require more height, but hardly less. Note that height calculations are up to browsers and do not necessarily use line-height values directly.
In your case, the best workaround is probably to use some logical table markup rather than floating. In a table, lines normally get aligned even though the box heights vary.
CONCLUSION: small sizes of Lucida Sans bold renders incorrectly (on some systems).
After a lot of testing all sorts of options, like setting line-height, using tables, trying different sizes, and vertical-alignments, and making measurements, I finally concluded that the problem is simply with the rendering of small sizes of Lucida Sans bold.
If you create two divs with borders, one using regular Lucida Sans at 10px and the other using the bold version, you can see that the bold one is noticeably shorter (in height).
When aligned to top, the bold font is a couple of pixels higher than the normal font.
Align to bottom, and it's a couple of pixels lower than the normal.
Even aligning to middle, it's still a pixel higher than the normal.
The BAD NEWS:
Lucida Sans is a default font for jQuery UI, and is generally a very popular font, which means this affects a lot of web pages.
It's not consistent across browsers, so tweaking
it to work for Chrome might throw it out on IE.
The GOOD NEWS:
It only happens on small versions of the font. I found that anything 13px or larger seems to render correctly.
At these small sizes you can easily substitute "Arial", "Helvetica" or similar, without anyone noticing the difference.
Thanks to everyone who gave their ideas, like using tables, line-height, etc. In the end though I think the only sane option is to avoid small versions of Lucida Sans. You can still use it for most of your web page, and just substitute with a similar more reliable font for sizes less than 13px.
hello i have this problem:
as you can see the left hand side there is a screenshot of how it is in chrome, right hand side firefox. the text has not the same height. the structure of the html is quiet simple. its just a div in which is a fieldset in that is placed a h1 tag. around that there is a border of 1px. that h1 tag has a height of 20px and even a line-height of 20px. next is a h2 tag with the same sizes. the problem is the text-height.
in firefox it seems that this is 1px lower than in chrome and safari.
i'm using a css reset from eric meyers in its latest version. so it should not beeing caused by that.
it would be great if someone have hints to help me out.
thanks alot.
The default line-height varies by a wide margin in different browsers, and for different font families at different font sizes. Setting an explicit line-height addresses that.
This is due to differences in how browsers handle subpixel text positioning. If your line-height is 20 pixels but font-size is 15 pixels, then the text needs to be positioned 2.5 pixels from the top of the line box. Gecko actually does that and WebKit just rounds positions to integer pixels. In some cases, the two approaches give answers that differ by a pixel.
In any case, making sure that your half-leading is an integer (i.e. that line-height minus font-size is even) will make the rendering more consistent if you really need that.
Try this:
div h1 {
-webkit-padding-before: 1px;
}
Another possible solution:
#media screen and (-webkit-min-device-pixel-ratio:0) {
div h1 {
line-height:19px;
}
}