When using a custom font via #font-face, it does render just as I think it should in Chrome. In Firefox, though, additional padding (top and bottom) is added to the font.
Here is my example page that outlines the problem.
Is there anything I can do about it?
FYI, this also happens in Firefox on Linux (and not in Chromium). I tried to load your font in FontForge and immediately got a warning:
The following table(s) in the font have been ignored by FontForge
Ignoring 'LTSH' linear threshold table
Ignoring 'VDMX' vertical device metrics table
Ignoring 'hdmx' horizontal device metrics table
I think the problem is that the VDMX (Vertical Device Metrics) table is defect:
In order to avoid grid fitting the
entire font to determine the correct
height, the VDMX table has been
defined.
This looks exactly like what happens in Firefox: somewhere the minimum and maximum height is incorrectly calculated. This is also clear when you select the text: the selection box extends to the utmost top and bottom of the line; if the h1 element really had padding, you would see a gap between the top and bottom of the line and the selection box.
Also, validation revealed that almost every glyph is “missing points at extrema”:
Both PostScript and TrueType would
like you to have points at the maxima
and minima (the extrema) of a path.
A quick search showed:
The only other problem I had was a
rather nasty condition called "Missing
Points at Extrema". With a font,
there needs to be a point (or node, as
they are called in Inkscape) at the
extreme left, right, top and bottom of
a glyph. Normally they are there
anyway simply because of the way your
glyph is built, but diagonal lines
with rounded ends often cause problems
[source, including picture (scroll down)]
Just Add:
line-height:1;
to your CSS rules
Related
I don't understand the difference between using BACKSPACE+CMD and just BACKSPACE.
I see that when I use BACKSPACE+CMD on a element in the Storyboard, that element becomes opaque, and using just BACKSPACE it deletes the element. I can't find the answer in the documentation.
As far I know, when opaque, it means the component (constraint or UI element) has been unistalled for a particular size class. For me, the combination is Command + Delete.
From About Designing for Multiple Size Classes (in bold the key part).
With size classes, a storyboard or xib file can be used for any
available screen area. You build your interface as it will look in
most sizes, then update only the parts that need to change when the
available screen size changes.
A size class identifies a relative amount of display space for the
height and for the width. Each dimension can be either compact, for
example, the height of an iPhone in landscape orientation, or regular,
for example, the height or width of an iPad. Because much of the
layout of an app does not need to change for any available screen
size, there is an additional value, any.
Hope it helps.
P.S. Did you check the key binding for your Xcode?
I am not pro developer and have small knowledge of html and css only. I am trying to work on a joomla website. I tried to add Google charts to my page. Actually it's a module that I am inserting to an article through load module function. But there seems to have a conflict and the chart is not displayed correctly. It seems that there are some conflicts with the issues but I am not sure how to figure.
http://goo.gl/v1GVWk
if you go to above link and go to tabs and open trekking map tab you will see the bug. The width of chart is very small. I want to display 100% so that it can be responsive. I tried changing the width to px as well but no luck.
Please help me. ..
The width of elements that are hidden is zero. Therefore, the chart thinks your window has a width of zero and ends up using its smallest width.
Try triggering a resize event on the window when the tab is shown, this should cause the responsive code to run.
I never used Google charts, but what you are experiencing also happens on Google Maps.
You have two options, either you use opacity (or maybe visibility hidden) instead of display: none, this will make the chart to resize automatically when the page opens.
The other option is to trigger the resize event, something like this... Google chart redraw/scale with window resize
Hope it helps
Even though the outer wrapper div#ja-google-chart-wrapper-404 is set to 100% width, two child elements are fixed at 400px. Specifically, the <svg width="400"> element that sets the image at a fixed width, plus the div that wraps it has the width set to 400px. Even though you have their parent set to 100%, if the image itself has a fixed width it won't expand to fill the space.
Check to see if there's a setting in your module or in the Google Chart itself that lets you set a different width (or none at all) on the inserted image.
One solution would be to resize the SVG element when the a#tab1-trekking-map is clicked. I just tested this in the Chrome console and it worked to trigger the map to resize to the full width of the container:
jQuery("#ja-google-chart-wrapper-404 svg").resize();
Add this (or something like it) to your other scripts that are called when your tabs are clicked. If the ID of the chart wrapper is generated dynamically you may need to adjust a bit, but triggering resize() (as stated by Niet and miguelmpn) should do the trick nicely.
Background
I have a standard three column layout where the first column is floated left, and the third column is floated right. The first column needs a full-height background.
This layout is for a template, so any of the three columns could have the longest content.
I can't change markup source order, so display:table solutions are not possible.
I can't add any DOM nodes.
The layout is centered with a minimum and maximum width, so I can't attach a vertically-repeating background image to the page with the built-in background color.
It needs to look OK in IE7, but IE8+ needs support.
Solution
To achieve the full-height left column, I created a pseudo-element on colLeft. That pseudo-element has fixed-positioning set to the viewport bottom, 100% height, and placed behind the left column. This solution is awesome because:
IE8+ supports pseudo-elements.
The pseudo-element is attached to the left column, so if the template doesn't have a left column, the background naturally isn't there.
By not setting a left or right attribute, the fixed-positioned pseudo-element stays with the left column (good for the centered layout).
Here's an example on CodePen.
(Make sure that the Document Mode is following the Browser Mode when viewing CodePens in IE).
Problem
In IE8 the full-height left column background only extends down to the initial viewport bottom (the fold).
I created another test with a new leftColBg node instead of the pseudo-element. This works as expected in IE8, meaning that the fixed positioning should work.
Here is the best explanation that I can find on IE8 and generated content: Why does a filter gradient on a pseudo element not work in IE8?
I think IE8 is incorrectly positioning the generated content, because it's not an "object" that contains content. Can anybody better explain this IE8 bug? Is there a fix?
What are the numbers in the Stretching box in the View sub-box Interface Builder's Attributes Inspector?
(as a side question - I suppose a respectable company such as Apple would have actually released documentation for its tools, as opposed to letting developers just guess everything; so, where's this documentation?...)
This blog post Karol seems to explain it pretty well. - http://macoscope.com/blog/stretchable-images-using-interface-builder/
Stretching properties are pretty simple (I don't think so, but the
articles does :).
The fraction of the original image left without stretching on the left
is specified by X The fraction of the original image that gets
stretched in the x-axis is specified by Width The fraction of the
original image left without stretching on the right is equal to 1 – X
– Width If we use 0 for Width the stretched area will interpolate
between the last pixel of the left part and the first pixel of the
right part The y-axis works analogously
Viewing a .storyboard file in a text editor (figures it's an XML file) revealed the answer: it is linked to UIView's contentStretch property.
FYI - this was deprecated in iOS 6.0 https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIView_Class/index.html#//apple_ref/occ/instp/UIView/contentStretch
(updated link)
Deprecation Documentation
Instance Property
contentStretch
The rectangle that defines the stretchable and nonstretchable regions of a view.
Deprecated
To achieve the same effect, use resizableImageWithCapInsets: instead.
For some reason a basic unstyled DIV element has extra height tacked onto the bottom when it contains a VIDEO element (and possibly other elements - I haven't tested with many types).
<div><video src="my_movie.ogv"></video></div>
I have the above line of code in a barebones base HTML file. With Firefox or Safari/Chrome's (if I use an .mp4 file instead of course) DOM inspectors on I see that the computed height of the DIV element is anywhere from 2-5 pixels more than the height of the VIDEO element.
This doesn't seem like expected and intentional behavior. If I put a P element in there instead of a VIDEO element, for example, the DIV doesn't have any of the extra height.
Does anyone know why the browsers are rendering this configuration of DOM elements in this way?
If your markup is as above and there are no special styles applied to it, then the behavior you see is required by the CSS box model; the space is the size of the font's descent, because the bottom of the video is placed by default on the baseline, not at the bottom of the text. In particular, see https://bugzilla.mozilla.org/show_bug.cgi?id=22274#c55 for an explanation in spec terms and https://bugzilla.mozilla.org/show_bug.cgi?id=22274#c37 for how to get rid of the space if you want to. You could also set line-height on the block to 0 to get rid of the space; which approach you take should depend on your other design constraints.