I have a html document that I am working on. When using MathJax however, the lines in fractions do not show up. After a bit of experimenting I realised that this was due to the font that I was using in the main body of the text. Is there any way to change the font of the MathJax text only whilst still only having to write $$ etc in the main text?
The difficulty with horizontal lines is due to some browsers dropping thin lines when they are less than a pixel wide, or if they fall too close to pixel boundaries. See MathJax Issue 1095 and MathJax issue 1279 for more details. In version 2.6 (currently in beta), the widths are given in units of px rather than em, which tends to improve the results.
EDIT: In terms of the font, the reason the change may make a difference is that MathJax scales its fonts to try to match the ex-height of the surrounding fonts. So if you change that font, it will change the scaling factor that MathJax uses, and that can affect whether the horizontal lines are dropped or not.
Note, however, that this is very browser, OS, and zoom-level dependent, so making a change in the font in order to "fix" it may only fix it for you, and may make it worse for others.
Related
This question is about the design of SVG-fonts.
I am using some third-party SVG music fonts for an application. The single glyphs of these fonts, are by default very huge in size. I was wondering what the reason for this could be. I can think of, this allows to do more fine-tuning work while designing the fonts, and since they are of course scalable, they should be down-scaled as needed when I want to actually use them. Is this true, or are there some other points to consider?
Also when I use the path's data of single fonts (e.g. in a svg file) and open the svg file in Inkscape the symbols are upside-down, so I have to apply scale(1 -1) to all symbols. Is there a reason why these fonts are designed this way?
It will generally relate to the tool(s) they are using. Font editors commonly have a default em size of around 1000 units. The reason for that is likely because font files generally use integers, rather than floating point, for their glyph coordinates. And 1000 gives you a decent three digits of precision.
For instance have a look at a description of the OTF/TTF glyf table
Can anyone please help me understand what resources the system uses to render fonts on the browser? For e.g. graphics card, memory, etc. Sorry for this vague question but I am facing a problem here. We have a custom font which gets rendered differently in same versions of safari browsers in different systems. For instances, in some systems the fonts appears to be a bit bolder and due to that it is taking up more space to get displayed. All the systems have same resolution.
Safari uses Quartz to render fonts on OS X. I'm not sure what it uses on Windows but it seem it doesn't use Windows rendering engine for that. Quartz utilizes some of the graphic card resources but it's still mostly software rendering.
Quartz has a number of rasterization options that can influence font appearance. One of the most prominent is Font Smoozing. Here's an article about Font Smoothing on support forums. Though, I don't think it should change the amount of space rasterized text actually takes.
You may have problems with fonts themselves. Maybe, different systems have different versions of the font you use and that changes the way it looks. Or your font doesn't get loaded on some systems and Safari uses a fall back font. There may be many reasons. It's hard to tell what exactly causes your problems just from your description.
I am developing some OCR software for small on-screen fonts. The fonts are rendered in the browser. I notice that they are rendered with ClearType onto the screen and the letters in the words seem to be the same no matter where they are located on-screen, although I have not checked many cases, just some common cases.
For example in the following image the letter a is repeated twice, once at the beginning and nice later 3rd from the end. The letter a looks exactly the same, pixel for pixel. My question is, is the letter a always the same for the same font and same font size within ClearType rendering? Does the same apply for all letters within the same font?
ClearType is here.
It might or it might not, depending upon the font, the size, and which version of ClearType is in use (and which application settings are applied for rendering). Microsoft's explanation of ClearType gets into this somewhat, and even shows an example where you can observe a case where two instances of a character do not render the same (see 'elle', on the right; both the 'e' and 'l' render differently in the second instance). This has to do with the use of fractional advance widths, which get resolved to the nearest 1/64th of a pixel. Thus you could potentially end up with many different instances of a single character (though as you can see, the differences are fairly subtle).
In short: I would not write anything that depends on any two instances of a character ending up exactly the same. They will be pretty similar, but not identical.
Let me describe the "battlefield" of my task:
Multi-room audio/video chat with more than 1M users;
Custom Direct3D renderer;
What I need to implement is a TextOverVideo feature. The Text itself goes via network and is to be rendered on the recipient side with Direct3D renderer. AFAIK, it is commonly used in game development to create your own texture with letters/numbers and draw this items. Because our application must support many languages, we ought to use a standard. That's why I've been working with ID3DXFont interface but I've found out some unsatisfied limitations.
What I've faced is a lack of scalability. E.g. if user is resizing video window I have to RE-create D3DXFont with new D3DXFONT_DESC while he's doing that. I think it is unacceptable.
That is why the ONLY solution I see (due to my skills) is somehow render the text to a texture and therefore draw sprite with scaling, translation etc.
So, I'm not sure if I go into the correct direction. Please help with advice, experience, literature, sources...
Your question is a bit unclear. As I understand it, you want easily scalable font.
I think it is unacceptable
As far as I know, this is standard behavior for fonts - even for system fonts. They aren't supposed to be easily scalable.
Possible solutions:
Use ID3DXRenderTarget for rendering text onto texture. Font will be filtered when you scale it up too much. Some people will think that it looks ugly.
Write custom library that supports vector fonts. I.e. - it should be able to extract font outline from font, and build text from it. It will be MUCH slower than ID3DXFont (which is already slower than traditional "texture" fonts). Text will be easily scalable. Using this way, you are very likely to get visible artifacts ("noise") for small text. I wouldn't use that approach unless you want huge letters (40+ pixels). Freetype library may have functions for processing font outlines.
Or you could try using D3DXCreateText. This will create 3D text for ONE string. Won't be fast at all.
I'd forget about it. As long as user is happy about overall performance, improving font rendering routines (so their behavior looks nice to you) is not worth the effort.
--EDIT--
About ID3DXRenderTarget.
EVen if you use ID3DXRenderTarget, you'll need ID3DXFont. I.e. you use ID3DXFont to render text onto texture, and then use texture to blit text onto screen.
Because you said that performance is critical, you can delay creation of new ID3DXFont until user stops resizing video. I.e. When user starts resizing video, you use old font, but upscale it using texture. There will be filtering, of course. Once user stops resizing, you create new font when you have time. you probably can do that in separate thread, but I'm not sure about it. OR you could simply always render text in the same resolution as video. This way you won't have to worry about resizing it (it still will be filtered - along with the video). Some video players work this way.
Few more things about ID3DXFont. There is one problem with ID3DXFont - it is slow in situations where you need a lot of text (but you still need it, because it supports unicode, and writing texturefont with unicode support is pain). Last time I worked with it I optimized things by caching commonly used strings in the textures. I.e. any string that was drawn more than 3 frames in the row were rendered onto D3DFMT_A8R8G8B8 texture/render target, and then I've been copying that string from texture instead of using ID3DXFont. Strings that weren't rendered for a while, were removed from texture. That gave some serious boost. This solution, however is tricky - monitoring empty space in the texture, removing unused strings, and defragmenting the texture isn't exactly trivial (there is nothing exceptionally complicated, but it is easy to make a mistake). You won't need such complicated system unless your screen is literally covered by text.
ID3DXFont fonts are flat, always parallel to the screen. D3DXCreateText are meshes that can be scaled and rotated.
Texture fonts are fuzzy and don't look very clear. Not good for an app that uses lots of small text.
I am writing an app that can create 500 text meshes, each mesh averaging 3,000-5,000 vertices. The text meshes are created once, then are static. I get 700 fps on a GeForce 8800.
Suppose I want to make a Web application which uses a fixed width and height, and I want the interface to fit on screen for common screen resolutions. Assume the application will only be used on laptops and workstations (and not on mobile devices), and it will be used by IT professionals.
What is the largest possible size I can make the application? I think the key considerations here are what is the smallest screen resolution commonly used and how much space to reserve for browser chrome, which may depend on whether the user has toolbars installed, etc.
Or should I make all the page elements resizable and go with fluid layout? That seems like it might be quite a lot of work.
Fluid layouts are great if your design works for it.
Otherwise, 960px wide is very common and works in pretty much any browser on a 1024x768 screen resolution (which is still VERY common).
As for height, people are generally okay with scrolling down, but if you need it in one window then you have to stay under about 500-600px depending on browser and what toolbars the user has installed.
960x600 pixels
You could use an analytics tool to figure out what resolution your current users are running.
You might try making only part of the layout fixed, and then using CSS's max-width/min-width and max-height/min-height to constrain what you must. Have decoration be fluid as much as it can (e.g. large background images shouldn't force the browser to be 1600px wide; just show as much as possible in the width available in the user's browser, without horizontal scrollbars; try setting the container width to 100%).
You could put a min-width of maybe 30em on a main text column, for comfortable reading (see Ideal line length for content), and perhaps an upper limit of something wide but still readable. It is unpleasant when browsing a site with a layout that crams the content into a small, fixed-size box, especially when it's only for the sake of preserving their design. If your design requires dynamic content to fit within a fixed size, the design could probably use some more thought.