here is the image:
I have tried zbar, pyzbar, zxing, and could not decode it successful.
Did anyone could decode this barcode?
The barcode image is totally non-compliant with the UPC/EAN symbol standards. All of the bar and space widths must be multiples of 1x, 2x, 3x, and 4x. If you look at the image's bars and spaces, they are all over the place.
Compare to the the following:
Related
I have this CSS:
.icon-plus-circled:before { content: '\e80f'; }
Which is displayed as a white plus inside black circle (Unicode I guess).
Need to make one more class, that would be a white minus inside black circle. But I can't find a Unicode code for that. Does anyone know?
Solved the problem. It was custom font.
There is no Unicode character for a white minus inside black circle.
There is U+2296 CIRCLED MINUS “⊖”, though it is not clear whether you want to use that or rather U+229D CIRCLED DASH “⊝”.
The notation '\e80f' means U+E80F, which is a Private Use code point. This means that the Unicode standard does not assign any character to that code point and promises to never do so. The code point is only for use by private agreements and has no meaning outside such agreements. The code you are using probably sets the font to a privately encoded special font, embedded with #font-face. While this generally works (when implemented properly) in the the sense of displaying the specific symbol, it easily causes trouble e.g. when content is copied and pasted (losing the font assignment).
Consider using images instead. Created in sufficiently large size and then scaled to font size with CSS, they do the job reasonably well.
Unicode number: U+002D HTML-code: '-';
Here is the complete table: http://unicode-table.com/fr/#002D
Unicode characters you might be interested in:
MINUS SIGN (U+2212): − −
HYPHEN-MINUS (U+002D): - -
CIRCLED MINUS (U+2296): ⊖ ⊖
CIRCLED DASH (U+229D): ⊝ ⊝
content: '\e80f' Which is displayed as a white plus inside black circle
U+E80F doesn't display as anything for me, that's a Private Use Area character that could render as anything or nothing.
There is no standard Unicode character for a filled circle with a plus or minus removed. Presumably you have some icon font where U+E80F looks like a circled plus. In that case you will have to look up the glyph set for that particular font to see if there is a matching minus.
None of the common icon fonts I know of use U+E80F for circled-plus so possibly you have a custom-made font (from Fontello or similar), in which case no-one can tell what the code point would be for a circled-minus without looking at the font file itself. Possibly the circled-minus might not have been included in it, in which case you'd have to create a new version of the icon font with it in.
Or, as Jukka mentions, switch to images (possibly SVG); icon fonts are a bit of a nasty hack.
I have an 40px by 20px image with 72 Pixels / Inch.
I would like to create a Retina display version.
What should I do? Double the size? Change the resolution?
And in which format should I save it? PNG? JPG? ...
I am using this image on a web site ...
In your image editor, double the size of your image to 80px by 40px.
In your markup set the width to 40 and height to 20.
<img src="example.png" width="40" height="20" />
You should save as png if you need transparency or the image is line art. Save photographs as jpg.
My answer is convert your image into SVG
Do you have Illustrator? If so save your image as SVG (and have a png as a fallback if you want).
<img src="images/logo.svg" alt="" />
<img src="images/logo.png" alt="" />
As long as you use Modernzr which can work to get svg friendly in most browsers.
You can see it here how it's done:
http://toddmotto.com/mastering-svg-use-for-a-retina-web-fallbacks-with-png-script/
Hope it helps :)
A retina display image (or high-density display image) is double the pixel size of a standard image - its scaling factor is 2.0. This means that yes, for your 40x20 pixel image, you will need to make an 80x40 pixel version (that is then displayed at double pixel density on screen). The format doesn't matter as much, both PNG and JPG will work fine (PNG will not degrade in quality with compression, but the file size will be larger than JPG).
However, the problem with high-density display images is that they take up more bandwidth, and are unnecessary for devices that don't have the high resolution or Retina displays. This means more data transferred over the network, inconveniencing mobile users and those with limited data transfer caps.
One solution is to use something like Retina.js. It's an open-source javascript client script that will automatically load the retina-sized image from your server and swap it in-place for the low-density version, if it exists. It follows Apple's standard for naming high-resolution images - #2x, so you can have HTML code like this:
<img src="/images/my_image.jpg" />
and the script will search your server also for /images/my_image#2x.jpg. If it exists, it will load it and swap it in-place without having to worry about messing with CSS.
Generally as of this writing there are two types of retina displays, hence you should create an image for each type.
For a 2× device, you would need to produce twice the logical pixels' width and height with a resolution of 144 pixels per inch (72 ppi ✕ 2).
For a 3× device, you would need three times the logical pixels with a resolution of 216 pixels per inch (72 ppi ✕ 3).
Examples of 2× devices are the MacBook Pro (released in 2012-2019) and most iPhone since the iPhone 4. Examples of 3×
devices are the iPhone 6 Plus, and the iPhone X. However the iPhone Xr is a 2× device.
Hence for your case you would need images in 80 px ✕ 40 px and 120 px ✕ 60 px for 2× and 3× devices respectively.
Retina displays are not dependent on the specific bitmap image format. You can use the original image format. For websites, you should use JPG for photographs and PNG for line-art graphics saved as bitmaps.
You should not just blindly enlarge images otherwise this would create a blurred results – it would no better than if you don't include any high-resolution versions in the first place. Either obtain the original higher-resolution version of the images (typically from vector graphic source) and downscale them or use a machine-learning based image enhancement solution such as Bigger Picture to "convert" your image into a higher resolution.
Photoshop gives you a couple options for resizing an image. For instance if the image is iPhone size you can increase the image size by 200%. Photoshop gives you a couple options for resampling of the image. Bicubic, bilinear and etc. This will remake the image at a higher resolution and interpolate the missing pixels. Hope this helps.
This is a really interesting article showing a nice option for dealing with high res images:
http://blog.netvlies.nl/design-interactie/retina-revolution/
Basically, it's saying that, if you make the image quite large (width and height) but then save it at quite low quality, it still comes out very sharp on retina displays. It means that you can use the one same image on all devices, and that the file size is very low, too, which is an extra bonus. You can set the width and height of the image in your CSS and/or HTML to set it to the visual dimensions you desire.
This article blew me away, and is my go-to approach for dealing with both retina-friendly and bandwidth-friendly images. Win, win.
You can use CSS opacity option.
This will give you an transparent look of your image based upon the value you set to opacity.
Try learning opacity: http://www.w3schools.com/css/css_image_transparency.asp
So I am experimenting with using icons in my CSS using base64 encoded pngs. I have used http://www.motobit.com/util/base64-decoder-encoder.asp to convert them. However, the pngs only have an 8bit alpha channel, the pixels are either fully opaque, or fully transparent, no partial transparency. This is leaving my icons with hard edges. Any ideas of a 24bit alpha channel is possible through base64_encode?
The encoder in that page may be buggy. I made a PNG with alpha channels in Photoshop, encoded it using PHP's base64_encode(), put it in an image, and it works. Take a look at this fiddle for HTML and this fiddle for CSS.
I'm using a transparent 1x1 image with a background image, to be able to use sprites and still provide alternative text for some icons.
I want to use a data URI for the image to reduce the number of HTTP requests, but what would be the smallest possible string to produce a transparent image?
I realize I could use data URI:s for the actual images instead of sprites, but it's easier to maintain when everything is kept in the CSS instead of scattered around.
After playing around with different transparent GIFs, some are unstable and cause CSS glitches. For example, if you have an <img> and you use the tiniest transparent GIF possible, it works fine, however, if you then want your transparent GIF to have a background-image, then this is impossible. For some reason, some GIFs such as the following prevent CSS backgrounds (in some browsers).
Shorter (but unstable - 74 bytes)
data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==
I would advise using the slightly longer and more stable version as follows:
⇊ Stable ⇊ (but slightly longer - 78 bytes)
data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7
As another tip, don't omit image/gif as one comment suggests. This will break in several browsers.
data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'/%3E
The final length depends on what it's gzipped with.
Smallest PNG - 114 bytes:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVQYV2NgYAAAAAMAAWgmWQ0AAAAASUVORK5CYII=
I think it must be a compressed transparent 1x1 GIF file (82 bytes):
data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==
Generated with dopiaza.org data:URI generator.
You can try the following SVG data (60 bytes):
data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg"/>
Standalone svg file would look like (62 bytes):
<?xml version="1.0"?><svg xmlns="http://www.w3.org/2000/svg"/>
See also:
Optimizing SVGs in data URIs
Url encoder for SVG (GitHub) / SVG CSS URI — Optimized replacer
This guy breaks down the problem via the GIF spec. His solution for the transparent.gif would be 37 bytes:
data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==
He goes even smaller by first removing the transparency, then the color table...
GIF89a specification
Header (6 bytes)
Consists of the bytes “GIF” and the version number, which is usually 89a.
Logical Screen Descriptor (7 bytes)
Without going into too much detail, this section of the file indicates the following:
The file is 1x1 pixels in size.
There is a global color table.
There are 2 colors in the global color table, the second one should be used as the background color.
Global Color Table (6 bytes)
Consists of 3 bytes per color, a byte for red, green, and blue, respectively. In our file, the first color is white an the second color is black.
Graphic Control Extension (8 bytes)
Used to indicate that the second color in the color table should be treated as transparent (can also be used for animation parameters, but isn’t in this file).
Image Descriptor (10 bytes)
A GIF file can actually contain multiple “images” within it, which keeps you from having to specify image data for parts of the image which have the same color as the background color. Each image block has a position and size within the overall image size. In the above file, the position is 0,0 and the size is 1x1.
Image Data (5 bytes)
One LZW-encoded block of image data. It takes 5 bytes to represent the single pixel the image has in it. The compression algorithm wasn’t designed to compress a single byte very well.
GIF Trailer (1 byte)
A single byte with a hex value of 3B (; in ASCII) indicates the end of the GIF.
Based on the required structures for a transparent GIF, it turns out that 43 bytes is pretty close to as small as you can get.
But, I managed to figure out one trick to make it a bit smaller. It’s mentioned in the standard that it is optional to have a global color table. Of course, it’s undefined as to what happens when you make a GIF without a color table at all.
When you have a color table index defined as transparent, however, GIF decoders don’t seem to care that there isn’t actually a color table.
So I changed the logical screen descriptor to indicate there was no global color table and removed the table itself, saving a total of six bytes, bringing the file size down to a mere 37 bytes.
Interestingly enough, Wordpress gave me a lovely list of error messages of GD complaining that this isn’t a valid GIF file, despite the fact that Firefox and the GIMP both open and display (is it “displayed” when it’s transparent?) the file just fine.
To make it even smaller, I looked to the biggest remaining “optional” block in the image, the graphic control extension. If you don’t need transparency, this block is no longer needed, and that’s another 8 bytes you can take away.
Source: The Tiniest GIF Ever.
I'm using following data uri to get an empty image: //:0
This is the smallest I found (26 bytes):
data:image/gif;base64,R0lGODlhAQABAAD/ACwAAAAAAQABAAACADs=
For empty image :
data:null
(it will translate into src=(unknown) )
BMP - 1x1 RGBA (transparent) - based on this - 194 bytes
data:image/bmp;base64,Qk1xAAAAAAAAAHsAAABsAAAAAQAAAAEAAAABACAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAD/AAD/AAAAAAAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ==
inside java-script it can be compressed to 106 bytes
"data:image/bmp;base64,Qk1x"+"9Hs3Bs5Q4E4B1C3w9995D/2D/2D/8/w999999993Q==".replace(/\d/g,c=>"A".repeat(c))
let s = "data:image/bmp;base64,Qk1x"+"9Hs3Bs5Q4E4B1C3w9995D/2D/2D/8/w999999993Q==".replace(/\d/g,c=>"A".repeat(c))
console.log(s);
You can use
data:null;,
<img src="data:null;," alt="My null image">
<img src="data:null;," alt="My null image" style="width: 100px;height: 10px;background: red;padding: 25px 16px;margin: 5px 15px;z-index: 5000;display: block ruby;">
or
<img src="data:image/png;base64, iVBORw0KGgoAAAANSUhEUgAAAAUA
AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO
9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />
Sometimes while typing in a textarea in Flex many characters will be rendered at one height then at some point on that same text line the rest of the characters are rendered a couple pixels lower than the rest. Here is an example, look at the last 'I' character, its low:alt text http://img.skitch.com/20091031-ej5n28akygnm3gmxcjx731ic85.jpg
Sometimes changing the font size will fix this but its not consistent and its not something I can detect (and fix even if I could). Anybody got an idea why this happens? It happens for embedded and non-embedded fonts.
Thanks,
Sam
Flash acts strange sometimes when movie clips, textboxes etc are not on whole pixels. Make sure the textbox has integers for it's coordinates. If it is in any movie clips, make sure those movie clips have integers for coordinates too.
The other option would be to fudge around with the anti-aliasing features in Flash, but that's always a hit-or-miss situation.