I was playing around with the thought of creating a WYSIWYG text editor from scratch just for fun. As I was getting deeper on the subject , I noticed that I do really know nothing about text editing although I use it every day. Its a much bigger task than I assumed, so I started to search for standards and specifications on the internet, but after hours without any helpful results I feel a bit lost on the topic.
Im mainly interested in the user interaction part. What should happen when a user clicks on the text, drags a selection, presses certain key combinations and so on?
Is there any kind of standard/specification for WYSIWYG GUI functionality editors?
You can check this spec from W3C https://w3c.github.io/editing/contentEditable.html and the Editor recommendations project by CKSource http://ckeditor.github.io/editor-recommendations/
Related
I am new to Qt in general, and I have been playing with it to get to learn about it since I have to develop a very specific text editor.
I want to know if anyone could help me understand which one is better (or the most indicated) for the development of a rich text editor. I have worked before with C and C++ but Qt Widgets seems like a very step hill for the time being and I am completely new to javascript in general.
Some of the settings that I would need to implement on the text editor for better context are:
Look for the user to be always connected to internet.
Transfer and receive data from another program.
Grant read only to the opened files and then permission to write on them when a button is clicked.
Has to work on linux and windows.
Needs to look great.
My context:
So far I have done a few little applications and even a little rich text editor on Qt Widgets, but since I was having problems with the GUI implementation that I wanted, I started looking for a way to solve it and found that Qt Quick might be the solution.
I have been trying Qt Quick, and for now on looks great, but I do not know if it has the capabilities to do what I have explained before. Or if it is better to use one or another.
I decided to create a new post since the one that I found looking for something similar is from 2014.
Also, the text editor for now only needs to work on desktop, but in a future might be on other devices and embedded systems.
Hi I have a requirement in which user will be able to write a Document like a contract.
User should be able to write in Block letters, use underline options and do some indentation while writing his/her document.
I am using ReactJS for the development.
I am not sure how we can achieve it using a text area or form.
Any help is highly appreciated.
Looks like you need to use a WYSIWYG (what you see is what you get) editors.
react-dragt-wysiwyg is a good example.
You might need to do some research to figure out
which editor fits your requirements
relatively easy to integrate into your system
doesn't slow down your site
looks reliable, i.e. the original authors are likely to keep supporting it
Suppose you're developing a web site and blind users will be a significant chunk of your target market. If the web site includes document editing functionality, what would be appropriate WYSIWYM tools? Are languages like Markdown, Textile and Wiki Formatting really accessible or are they inconvenient to blind users?
I'm a blind programmer and while I haven't used most of the languages you mention I've found that any markdown language is fairly easy to use if you have the desire to learn it. I've had no problem using either HTML or several markup languages for wiki's. Part of it will depend on how invested the users are in your site. If it's a site that will be visited infrequently or for short periods of time, it's much less likely that a user will take the time to learn the required markup whether they are blind or not. Unfortunately, I have not found an accessible JavaScript WYSIWYG editor but I find it easier to manually enter the markup so haven't looked very hard.
the first question is: how important is semantic structure? could you get away with plain text. You could do simple parsing like treating blank lines as paragraph markers, treating a series of lines which begin with * as a bulleted list, identify URLs and make them into links, etc.
As a blind developer myself, I have no problem in understanding languages like Markdown. But if it's a syntax I'm unfamiliar with, I'll only learn it if I expect to use the site very often, or care deeply about the content.
Two final thoughts come to mind: while I certainly experience some accessibility challenges using TinyMCE, you could develop something much simpler - provide less than 10 formatting options, like inserting hyperlinks, making lists, centering text, setting the style (such as heading) etc.
And lastly, when I talk to non-technical blind people, they often just write their content in Word and paste into a wiki or blog post. This sounded strange when I first heard it, but it does make sense. So an ideal solution would accept pasted in content.
In closing - it depends how important this is, and how much effort you want to expend. Maybe a Markdown editor with a live preview (like on this site), buttons for inserting simple formatting like URLs, and the ability to paste in rich text would tick all boxes :-)
On a web page, the most accessible embedded text editor for blind users is one that uses standard HTML, such as a <textarea> element, with a corresponding <label> element:
<label for="editor">Enter your text here using wiki markup:</label>
<textarea id="editor"></textarea>
If a WYSIWYM tool is built using standard accessible HTML, then blind users can easily enter text into it, with full confidence that they're entering text in the right place. Then the question becomes: Which is the better markup language? They all require memorization, but some may be more intuitive than others. One way to find out which is best would be to do some usability testing with a wide variety of target users. Also be sure to providing easy, accessible access to syntax help.
Picture yourself working in pure text 80x4 display (just open a console and resize appropriately), then use vi/emacs/ed and you'll soon realize what markup will get in the way.
Try to do as much work as possible to understand plain text, else use light markup like POD, finally things like AsciiDoc are very powerful but needs training.
I don't know about WYSIWYG/WYSIWYM tools, but I do know that complying with W3C standards (especially their HTML5 en CSS3 drafts) while writing your own editor code will help a lot.
In CSS you can specify speed and intonation of speech. In HTML you can specify alternative text (alt attribute in many elements) that screen readers are compatible with. Be sure to know when to use the abbr and the acronym elements. Use the former when you want the screen reader to read the meaning of an abbreviation and the latter when the acronym should be read as a word (e.g. ASAP, NATO and OS).
For the editor itself, I recommend creating a WYSIWYG editor that uses divs and spans. Screen readers will understand easily the structure of a document. For the current line, use a text box; for every other line that's not being edited, convert the contents immediately to valid HTML.
If you find a good tool, be sure to post it here. I'm looking for one too. :-)
I'm new to QT, and am trying to figure out the best means of creating a WYSIWYG editor widget for a custom markup language that displays simple text, images, and links. I need to be able to propagate changes from the WYSIWYG editor to the custom markup representation.
As a concrete example of the problem domain, imagine that the custom markup might have a "player" tag which contains a player name and a team name. The markup could look like this:
Last week, <player id="1234"><name>Aaron Rodgers</name><team>Packers</team></player> threw a pass.
This text would display in the editor as:
Last week, Aaron Rodgers of the Packers threw a pass.
The player name and the team name would be editable directly within the editor in standard WYSIWYG fashion, so that my users do not have to learn any markup. Also, when the player name is moused-over, a details pop-up will appear about that player, and similarly for the team.
With that long introduction, I'm trying to figure out where to start with QT. It seems that the most logical option would be the Rich Text API using a QTextDocument. This approach seems less than ideal given the limitations of a QTextDocument:
I can't figure out how to capture navigation events from clicking on links.
Following links on click seems to only be enabled when the QTextEdit is readonly.
Custom objects that implement QTextObjectInterface are ignored in copy-and-paste operations
Any HTML-based markup that is passed to it as Rich Text is retranslated into a series of span tags and lots of other junk, making it extremely difficult to propagate changes from the editor back to the original custom markup.
A second option appears to be QWebKit, which allows for live editing of HTML5 markup, so I could specify a two-way translation between the custom markup and HTML5. I'm not clear on how one would propagate changes from the editor back to the original markup in real-time without re-translating the entire document on every text change. The QWebKit solutions looks like awfully bulky to me (Learning WebKit along with QT) to what should be a relatively simple problem.
I have also considered implementing the WYSIWYG with a custom class using native QT containers, labels, images, and other widgets manually. This seems like the most flexible approach, and the one most likely not to run into unresolvable problems. However, I'm pretty sure that implementing all the details of a normal text editor (selecting text, font changes, cut-and-paste support, undo/redo, dragging of objects, cursor placement, etc.) will be incredibly time consuming.
So, finally, my question: are there any QT gurus out there with some advice on where to start with this sort of project?
BTW, I am using QT because the application is a desktop application that needs platform independence.
Given that I got no advice here, I decided to go with the QTextEdit approach, although I'm actually using a QTextBrowser that is set to be editable so that I can capture link navigation events. I will be using QTextCharFormat's with the link names set to unique identifiers in order to convert from the QTextEdit back to the custom markup. The QTextEdit supports images already, so I won't have to deal with those.
I think I will hit the biggest roadblocks with the fact that I need to be able to insert/grow/shrink tables whose cells can have Excel-style functionality. I have not yet figured that whole process out.
How do you guys handle translation/internationalization of your ASP.NET applications? How do you work with your translators?
We have ASP.NET apps that need to be available in German, French, Italian, English. We use string resources everywhere. However, more than once, our translators have told us just getting a bunch of "txtMyTextbox.Text" and then a German text to be translated is next to impossible to deal with - the context is missing.
So are there any other solutions available? Due to the fact these translators are dispersed all over Europe, we cannot get them to fly in and do their work "on location" - there has to be a way to send them the text fragments to be translated, along with some context, and let them do their work.
Is there any tool out there that would allow me to package up my ASPX pages and ASCX controls along with the text resources, and that would actually visualize them to the translator (without him having to install and host IIS and all) ? I vaguely remember there was a lot one tool in my olden Delphi days that did that - visualize the form (without the real app running), and allowing someone to pick the labels and translate them.
Or would there be a tool that would allow me to make screenshots of my ASPX pages and highlight all label and display their control name ("txtMytextbox") in red, so that the screenshot could serve as an orientation help for someone working on translating a list of labels?
Any hints are most welcome and highly appreciated!
Marc
take a look at the Lingobit http://www.lingobit.com/
How about going around ASP.NET's insternationalization scheme and using a diferent approach, using .po files like the "rest of the world" . The actual text is the key, and translators see that text qhen they are translating. Works pretty well.
http://www.expatsoftware.com/articles/2010/03/fixing-internationalization-in-aspnet.html
describes this.
Make your resource keys more meaningful. This will give them some context
Can the translators get access to a running app? If so, you could set the tooltips of all your labels to be the resource key. That would allow them to mouse over a label to see where its string is coming from.
As your translators become more familiar with the product, they'll be able to better cope with the lack of context. The first time around is a little rough, and you'll need to go through a few rounds of testing and translation revisions. There's not much you can do about it.
Here is the article written by Scott Hanselman. Hope it helps
Globalization, Internationalization and Localization in ASP.NET