I'm working on an ASP.NET website that needs to be internationalized. I'm using .resx files (essentially key-value pairs in a file) to populate static string fields on a page in different languages depending on the chosen culture/locale. I'm implementing Japanese and getting some stubborn vertical strings.
When copy and pasting them into the .resx file, they are horizontal (source of strings is Google Translate, for testing purposes). All of the strings appear normal, but one always displays vertically. The misbehaving string is a few div's deep (like all of them) and only has font-size, font-family, color, and an uppercase transform applied to it.
Removing any or all of the above rules does not change the orientation of the text. I've cleaned the formatting off the offending text with Notepad and shortened it (to ensure it wasn't a length problem). I'm stumped as to why this particular string is stubbornly vertical.
Here is the text in question: ログアウト
(Translation: Logout)
Edit
Clarification of the issue.
What it should look like:
The vertical text in question:
How can I force vertical text to be
horizontal?
Other than the title, I don't really understand your question. I'll take a guess anyway.
Try adding white-space: nowrap to the div that's misbehaving.
Recently I was doing some learning about right-to-left on the web and learned that Unicode characters have a directional property associated with them at the character level. So this might have something to do with that, though I certanily wouldn't know how to ascertain that or fix it, especially given that Google Translate is the source of the strings.
It happens quite often for Asian scripts (not just Japanese but also Korean and Chinese) to have text rendered incorrectly. Usually you just need to play with element width, especially if it is part of HTML table.
Related
I am in the process of writing a text editor. After looking at other text editors I have noticed that a number of them refer to a "soft" versus "hard" wrap. What is the difference? I can't seem to find the answer by searching.
A hard wrap inserts actual line breaks in the text at wrap points, with soft wrapping the actual text is still on the same line but looks like it's divided into several lines.
It's usual for text editors to auto-wrap text into paragraphs with hard newlines, but it's less common for the text to be re-flowed into a nice paragraph if you come back later and edit/add/remove words later on. (You can do this manually in emacs with M-q.)
This is rather annoying, since obsessive compulsive people like me then go back and have to manually re-insert the hard breaks at the appropriate points.
On the other hand, soft wrapping is annoying because most all command line tools use line-based diff-ing (version control is where this becomes most noticeable to me). If you've got a 1/3-page paragraph that's soft wrapped and fix a typo, it's basically impossible to see where the change is in a regular diff output or similar.
soft : The text in the textarea is not wrapped when submitted in a form. This is default
hard : The text in the textarea is wrapped (contains newlines) when submitted in a form. When "hard" is used, the cols attribute must be specified
Reference: W3Schools
I need to find a feature or tool that allows me to programmatically create a file in which I will have a sized textbox with text that automatically scales to fit its dimensions and still be visible.
Here is an example of what it would do:
On the left side, an already sized textbox has some text. The text is too long so it goes "out" the textbox, therefore the tool would "scale" it to a size that makes it visible only in the textbox, and not outside. It could scale by changing font size, or "zoom" in any way.
I tried looking at OpenOffice Writer & Impress, Microsoft Word & Powerpoint, with no success. It seems really difficult with CSS according to the resources I could find.
Some resources I found (like Fitty, which is in Javascript. Not what I need, but still possible) will scale it in other manners that do not correspond my needs because they keep the text on one line, and I need them multiline...
See some wrong examples:
Does anyone know any tool that would have such feature?
I have a site with a number of written documents that are rendered as images. If I wanted to make them accessible to visually impaired people, it would seem that I would need to add the text somewhere.
Each document is rendered as a series of images, one for each page (see this, for example). Would I want to each page's text into its corresponding image's alt attribute, or is there a better way to do it? And, if the alt attribute is the way to go, can I put the entire document in the image for the first page, or is it best to have the text in each attribute correspond exactly to the image it's in?
I would not use the alt attribute as it is used for short descriptions only.
Making all this text accessible would mean rendering it in HTML. In your document, there are lists, there are tables, there are definition lists ; all this needs to be semantically described via HTML so that it is accessible. You would not be able to do this via the alt attribute.
I think of multiple ways you could make this accessible:
have empty alt on all img and render all the text in HTML below the last image. The text can be visible to all, or only to those with screen readers as you wish (via the use of specific CSS, see the "sr-only" class of Bootstrap for example). If you want the text to be visible to all without taking too much visual space, you could hide it behind a toggle button (with the aria-controls and aria-expanded attributes).
on each img, have a short alt attribute and a longdesc attribute. The alt is the title of current page, like "Table of Contents". The longdesc is a link to an HTML page having all the text on the image.
after each img, have some HTML with the text of the image. This description can be visible to screen readers users only. Link each description via the aria-describedby attribute on the image.
I'd go with the first solution, because it's generally the simplest to deal with, and it benefits all users.
Most screenreader software won’t announce an entire page’s worth of content from an alt attribute, let alone a whole document. They have different cutoff points, but alts are intended to give short (a sentence or two) descriptions of pictures rather than large quantities of paragraphs, headings, tables, etc. You can test with a free screenreader (VoiceOver for Apple devices, or NVDA for Windows) to confirm this for yourself.
A better option would be to extract the text using OCR and put it into HTML or a Word doc that uses templated styles. That way people who can’t see the text can still have it read out plus they’ll be able to use all the usual navigation shortcuts like tables of contents and headings. You can still put any charts or graphs in as images with alts, and the amount of text you’d need to describe those would be much shorter and easier to write.
So I've been working on some project of mine and long story short, I have to correct paragraph stylings and so on, because it didn't exprot correctly. Now I've been doing this for over a 1100 paragraphs and it was as it should be until the paragraph 1142 which when I apply style deletes everything that is after it, for no apperant reason. This only happens with this paragraphs, all the others befor it and after it apply styles correctly. I really dont get this. Thanks ! (since I dont have 10 reputation ill link the image http://i.stack.imgur.com/5K7ec.gif)
Not a programming problem; it's PICNIC.
Looking closely at the image, I see the newly applied style does not allow hyphenation. The single word in that paragraph is too long, and since you do not allow word breaks, InDesign tries to move it to a next frame, hoping that will be wide enough. (Apparently it is not.)
Enable hyphenation, or break the word in two with a space, or make the column wider, or use a smaller font. With your style parameters it simply does not fit.
What is the benefit to add null alt=""? is it only to pass validation or it has more reason
and how it should be write?
like this, no space
alt=""
or this with one blank space
alt=" "
To get your XHTML validated. The alt is a required attribute on images.
Adding it empty is however a sign of laziness from programmers (although I admit I also do it for images that are not key to site navigation like little decorative elements and so on).
P.S. If you have decorative elements like shadow components, certain ornaments you can add them not with images but as a CSS background, thus avoiding the need to write an alternative text and keeping your markup clean of non-content stuff.
Other answers have pointed out the requirements in the standard. Here is a practical example:
Given blank alt text, lynx will render:
Given a missing alt attribute, lynx will render:
filename.jpg
You don't want your content to have irrelevant filenames scattered throughout.
For images that have no suitable alternate text (i. e. pictures that don't carry any semantics, such as decorative elements), the alt attribute should be empty. Empty meaning empty, not a single space (which is a convention and recommendation but a good one).
The alt attribute must be specified for the IMG and AREA elements. It is optional for the INPUT and APPLET elements.
While alternate text may be very helpful, it must be handled with care. Authors should observe the following guidelines:
Do not specify irrelevant alternate text when including images intended to format a page, for instance, alt="red ball" would be inappropriate for an image that adds a red ball for decorating a heading or paragraph. In such cases, the alternate text should be the empty string (""). Authors are in any case advised to avoid using images to format pages; style sheets should be used instead.
Do not specify meaningless alternate text (e.g., "dummy text"). Not only will this frustrate users, it will slow down user agents that must convert text to speech or braille output.
Implementors should consult the section on accessibility for information about how to handle cases of omitted alternate text.
—HTML 4 specification. Section 13.8 How to specify alternate text
I'll add this as an answer as well (originally a comment on another answer), since it kind of makes sense to do so.
Images used for styling the page (and therefore has no real "alt" usage) should be inserted through CSS and background-image and its relatives, not through markup. That way you do two good things at once. You keep your design in your stylesheets, and you keep unsemantic code out of your page.
Although I do think the "semantics is god"-movement has failed to see the fail that is div and span, and the inherent ambiguity they produce, I still think a div with background-image is better than an img tag for styling.