Apache OpenOffice (AOO) Bugzilla – Issue 3395
Reveal formatting codes
Last modified: 2017-05-20 10:11:43 UTC
One of the good things about WordPerfect is its "reveal codes" feature whereby one can see the limits of formatting and any nested formatting that has taken place over the document's history. Inclusion of such a feature would significantly improve the useability of OpenOffice's Word Processor & give it a distinct advantage in WYSIWYG output over MSWord.
Reassigned to Christian.
*** Issue 6489 has been marked as a duplicate of this issue. ***
Reassigned to Bettina.
The main feature that make me stick to WordPerfect is the Reveal Codes feature, that allows to find and change/eliminate any code, so that the document ends "cleaner" and with a much better control of features. I cannot help with programming, but Im sure that this enhancement will be much appreciated in OpenOffice or any other program that possesses it.
I would also like to say that this would be a great feature to add to OO. I have used WP for over 10 years now and haven't used anything else becase of this feature. I don't think the idea would be to hard to implement because the file format is xml but I am not sure how OO stores the file internally.
This should be a very low priority. Styles provide a more than adequate solution to most of the things that this crutch is designed to solve. Arguably, enabling this crutch would further encourage bad formatting habbits.
I disagree. Most (IMHO) formatting problems arise from the wordprocessor applying styles where it "thinks" they are appropriate as distinct from where they are intended. Being able to view & edit formatting codes takes all the guesswork out; life is much more dull, but a whole lot more productive.
The "Reveal Codes" should be a really good enhancement. I work frequently with styles, and sometimes I stay puzzled when my clicks don't work. If I can see what's happening in document source I should guess better what to do. See what's happening in the xml zipped file is good, but show it with a menu command would be wonderfull. Ps. I never used WordPerfect....
I've even gone far as by editing the document styles in my personal documents to include colour to show some visual markup of the styles (similiar to syntax highlighting in Developer's IDEs). Thus I can easily see what styles are applied to what text. If you've not realized about this. One can emulate reveal codes by... Using one (rough draft) stylesheet which is modified with colour to give the document a visualized markup look-&-feel. Then apply another (final draft) stylesheet which does not have the above colour markup, before printing out the document or rendering to PDF. With reveal codes, you don't have to go through the above "stylesheet-change" rituals, nor have to prepare those two seperate stylesheets. DISCLAIMER! I don't use WordPerfect.
Styles are not a solution that make Reveal Codes unnecessary. I consider myself a WordPerfect middle-powered user, I make extensive use of styles and I find Reveal Codes indispensable. I believe that Reveal Codes *can* be implemented in Writer, and I'm designing a draft to describe how it can be implemented. The draft is available here: http://digilander.libero.it/bilotta/giuseppe/rc-proposal.sxw Interestingly, while writing the draft (in Writer, with Styles) I had to curse often just because of the lack of the feature, so ... (Finally, the owner of this issue or any other moderator should set the O/S to "All" (and pump up the version, since the need is still there in OOo 1.1 ...), or can these things be done by anybody?)
(Don't pump up the version. The version is just to show which version the problem was first identified with.)
I have to vote for this one. As an old Word Perfect user, I really miss being able to see what's going on "behind the scenes". I have to agree that the application of styles is NOT a substitute for being able to see exactly what formatting codes are being applied, and where. For instance, this feature would save a lot of time trying to hunt down an unwanted hard page break. Right now, the only way I know of to find and remove it is to hit delete from the top (or backspace from the bottom) until the text from the next page moves up. This unfortunately, in most cases, also removes the style applied to the text that has moved up, and possibly a character or two, and so the text has to be re-typed and the style set again.
Along with the Word Perfect Filters that have a high vote count this feature has not been included in the release specifications for "Q". This requested enhancement is in the top 13 voted on issues. I guess requested features which have high votes are not looked at unless whoever makes the decisions thinks it is important to them. I would request that this be included in the "Q" release of OO because of the amount of interest by end users.
*** Issue 23487 has been marked as a duplicate of this issue. ***
Reveal codes is a key element to gaining support from anyone who is technically minded. These people like to look under the hood and see why things are working the way they do. They want to control the document. Those who don't think this way will probably never turn on this feature, but it will be very handy when they take their messed up document to their 'geek' friend to have him fix it for them. Every time I used MSWord it was because I had to and I hated it. Sooner or later some formatting goes amiss and you need to throw some part of the document away to fix it. Now I have Open Office, but the Writer was patterned after MSWord so I don't like it either. This feature will help add the missing control that I need to produce precise documents.
If you want to see what's going on "behind the scenes", unzip an .sxw file and take a look at the files. Everything's there.
Sorry! That was incomplete. If you need to or want to make changes to the unzipped files, you can. Then rezip them and rename them as .sxw files. Easier, if what you want is productivity instead of curiosity or interest in the guts of the program: Mark the area where the error is, select Format > Default and reorganize them by modifying the relevant styles or edit them inline.
How convenient!
I add my vote for this. I think it goes beyond being a good idea ... I think it's a necessity for an open source program. A lot of folks have posted excellent workarounds for seeing the gory details of the formatting, but these are all for _technical_ people (things like unzipping the file and editing the raw XML). One of the things I noticed when I used to support WordPerfect users is that reveal codes allowed non-technical users the level of control that was usually reserved for technical people. The fact is, a reveal codes feature isn't for technical users, it's for all users, and the ones who don't have the ability to unzip the file and read through the raw XML are the ones who will benefit the most! I'm interested in helping the coding effort to develop this, but I'm not familiar with the OOo codebase, so there'll be quite a learning curve for me.
Okay, a little indication of my own experience. I went from Word to WP and got a lot of good from "Reveal Codes" as it helped me find mistakes in formatting, extraneous format coding and so on. It was far superior to Word in that, for Word, sometimes the screwed-up coding simply could not be fixed. With WP, I could spend ten to fifteen minutes, find the offending code and delete or correct it. It didn't take very long if the mistake was close to the text that concerned me, but the main use was for an error a couple or more lines away from where the error became apparent. With OOo, at one time I had a real problem with screwed-up code and found no way to make sense of the encodings in the unzipped file. I, too, advocated "Reveal Codes" as a solution. Then I discovered something that completely eliminated my need for "Reveal Codes." The purpose of "Reveal Codes" is to correct errors in the hidden formatting of the document. For the user, if the error can be eliminated, there is no need for "Reveal Codes," yet we have all had situations where there where such things as <B><B>text</B> and removing the Bold from the text now produces an entire document in bold (up to the next </B>) since there is a doubled <B> command. What to do? That is where OOo's solution is actually superior (that is to say, much faster) than "Reveal Codes." Instead of taking the time to open the "Reveal Codes" window, locate the offending code and removing it, we can simply select the area with the problem, then enter Alt-O,D (Format > Default) and all character and paragraph (if an entire paragraph is marked) formatting is removed and we're left with the default formatting. Now we can reset the formatting the way we want it and our problem is solved. I am a professional writer, which means I make a lot of writing mistakes daily. I have this kind of problem maybe once or twice a week and the Format > Default has proven MUCH faster and more efficient than "Reveal Codes." All the original discussion about this topic had to do with finding and locating mistaken format encoding and almost all of us who commented on it had experience with "Reveal Codes." The developers tried to let us know that the entire structure of OOo was NOT well designed to implement "Reveal Codes," as opposed to WP which was designed from the ground up with that feature in mind. In fact, it would have meant a complete redesign of the core structure of OOo, which was why they were not inclined to introduce it. It was not a developer who pointed out the use of Format > Default to me, but an ordinary user. It was a revelation to me because, using that solution, I had no need for the more time-consuming "Reveal Codes." Re-writing millions of lines of code to satisfy those who want to see the codes is far more a chore than opening the zipped files that make up the .sxw files and correcting formatting or positioning problems and, for the headaches of graphic and table placement, it remains almost the only solution (the developers are working on those issues). But for the normal user need, Format > Default is superior to "Reveal Codes." To reiterate, I claim superiority for OOo's solution based on speed, time needed to correct an error and reduced frustration.
I have to disagree with the previous person. Yes there are a lot of technical workarounds for reveal codes, but they are not a good solution for this. I also agree that removing all formating will work also, however this is also a waste of time unlike what the previous person has said. I have done this procedure and found it more time consuming to reformat my text when I could have simply removed the offending code instead of reformating my document or the offending text. I also think that the number of people who use word perfect that look at this product who understand the importance of this feature will not use this product completely unless they are forced to do so. I know many WP users who will not convert to Word or OO because they do not have this feature. They are profesional writers who work on long documnets every day. This is a feature that is a must for them and for me. Have you ever imported a doucument with some of these fiters or cut and pasted form one document to another. I have and honestly it does not work very well in any Word Processor, but with reveal codes it is easy to clean up the document in a fairly fast time without having to redo all the formating. I respect that some people love to redo things over and over again but it is much easier to fix a few offending things than redo all the formating. The sad thing is this is one of the top 10 voted on issues for OO and it has not been addressed by the core developers. It seems that this really is not a community directed project but a project directed by the developers.
If I have understood the technical side of the discussion correct, a "reveal Codes"-functionality could easily be applied on the file-format (cf rblackeagle Wed Feb 25 08:31:26 -0800 2004), but that there is a technical problem in relation to how OO implement it with the screen-funcionality of OO. Cf: http://wp.openoffice.org/servlets/ReadMsg?list=dev&msgNo=682 I was wondering: Would it be possible (perhaps only as a temporary solution) to build a small tool (that can be activated from within OO) that makes a second screen pop-up, showing the unpacked (and perhaps slightly translated) codes that rblackeagle is talking about, and making it possible to edit these codes. In the outset, there will of course be a problem about SEEING how the changes affects the actual text in the WYSIWYG-window (at least if you scroll to parts of the text that are not presently visible in the WYSIWYG-window). But a further development could perhaps let the "tool" send information back to the WYSIWYG-window about where the cursor is situated, and let it scroll down to the same placement. Then the two windows could be shown simultanously, and if the new tool is situated in the bottom of the screen, it would be difficult to see the difference from the original WP-"reveal codes". It is just an idea. Unfortunately I am not a programmer, so I don't know whether it would solve the problem?? Ejvind Hansen
Interesting suggestion, and it would satisfy the needs of those whose need for "Reveal Codes" comes about from more complicated issues than a simple doubling of formatting code. It also sounds like a possible solution. The hard programming task would be to coordinate the position of the coding file with the position of the formatted text file in the other window. Unfortunately, I can envision all sorts of complaints based on the fact that the XML coding is far different from the coding found in WP's "Reveal Codes." There would also be a new set of complaints for this change or that one to the coding features. That would dilute developer interest in other serious debugging and enhancement issues, unless we got a new development team of experts in both WP and OOo -- something that would NOT distract from other development.
I continue to think about this. I have never had an occasion using OOo where I've had to change coding on more than a few words, although I can envision perhaps a paragraph. If more changes need to be done than that, it would seem to be due to a refusal to learn how to use styles rather than a real need for "Reveal Codes." I HAVE noticed that some people seem to have an almost religious opposition to learning how to use styles (which are really easy) I suspect because they are so poorly implemented in WP and MS Office. In OOo, they are easy to use and allow complete reformating of an entire document with minimal effort. If a person is having massive problems with bad formatting issues affection more than a paragraph, I would direct that person to one of the many available documents on how to use styles. I believe I was one of those who resisted because of my bad experiences with them in both WP and MS Word, but it took me less than three days to master their basic uses and I keep discovering new and creative ways to use them years later. (I just learned how to custom-design new fonts based on existing ones using styles.)
We are only using WordPerfect in our office because of this feature. All other machines which people mostly use for browsing and light work all have OOo on it. If this feature were added, we'd throw all our old WP and Office discs away. Samuel deHuszar Allen
*** Issue 28997 has been marked as a duplicate of this issue. ***
I have been using WordPerfect as my primary word processor for over a 15 years and I still use it for my current work (I started with the old DOS version, Windows versions and use the Linux version today). The ONLY reason I still use it is because of the Reveal Codes. I am a research Biologist, I have tried MS Word (hate it) and Open Office Writer but the fact that there is no way to see the codes has kept and will continue to keep me from changing over to Open Office writer completely. Don't get me wrong I like the fact the Open Office is here (I even tried out the first Star Office before Open Office)! When I have to use Word documents I use Open Office, I also use the Spreadsheet and Presentation packages regularly, but not the Writer. I write both large and small documents all of the time. I have used paragraph styles (don't really like them). In some documents I have to use several different paragraph styles and changing the paragraph style is not the solution to the problem! In fact it can make the problem worse! I write scientific documents, including papers, books, data sheets and other manuscripts with lots of different formatting needs, and I can do it very quickly and easily in WordPerfect, messing with paragraph styles can cause problems with other parts of the same paragraph or document. If Open Office Writer is going to become the dominant word processor it need a function like Reveal Codes. Dr. Fredric Govedich
*** Issue 2216 has been marked as a duplicate of this issue. ***
As this feature does not belong to the keyfeatures planned for Q, there is no chance to get that intgrated into OO.o 2.0, it also would mean an extensive rebuilding for Writer. But is it an often asked and sensefull request for the next milestone. Hello Andreas, please take over this highly voted enhancement for concidering it for the next milestone. Thank you.
Yes, we will consider this. There are some advantages from reveal codes. We should implement reveal codes or find another intuitive methods to show character attributes and to put the cursor into or behind character attributes and so on...
I am writing an open source "reveal codes" macro for Writer. I have posted two versions for discussion on my OOo web page: http://homepages.paradise.net.nz/hillview/OOo/ I have started a discussion thread about it in the Writer forum: http://www.oooforum.org/forum/viewtopic.php?p=36976 I would really like some feedback on this, otherwise I will simply drop it as not being of interest to anyone. If what I have done is hopeless I would like to know that too so that I don't waste any more time on it. Cheers, Ian Laurenson
>>>ama Nice to hear that the feature has now been accepted for implementation. I think that most of us already had realized that it was unrealistic to hope for it in the 2.0-version. >>> Ian Laurenson This really looks very promising!!! I have had a short look into it, but will not report my comments before I have had a closer look into it. But to all you other RC-fans: DO take a look into Ian's post and forward your oppinions to him. As is clear from bh & ama's comments, we cannot count on this feature in the main program in the near future.
How does ths issue relate to RevealCodes project: http://wp.openoffice.org/rcodes.html
reassigning & adding keywords according to new RFE process - Sophie
adding keywords according to new RFE process - Sophie
*** Issue 34876 has been marked as a duplicate of this issue. ***
*** Issue 45591 has been marked as a duplicate of this issue. ***
I too would like to express my desire to see WP style reveal codes added to OO. Reveal code is what keeps me using WP. I find if indespensible when trying to figure out where "the other guy" bungled the formatting.
I will add my support for Reveal Codes as well. Reveal codes could have saved hours of work on converting a few MS Office documents. Styles did weird things as the documents original imported formats were strange as well. I am going to try Ian Laurenson's macros.
Please change OS to "all".
*** Issue 50501 has been marked as a duplicate of this issue. ***
***** Please, change the summary of this issue to "Reveal formatting codes" to help avoid duplicate requests! ***** I am strongly in favor of this feature, which I had no idea WPerfect already implemented. I have recently proposed the same feature (Issue 50501, rigthly marked as a duplicate by "cloph") and compared it so "source mode" in HTML, or the editing window of TeX. For the time being, as far as Informatics is concerned, the best of software as far as a user is concerned is to have _both_ worlds: good WYSIWYG features and good "under the hood" features control.
adding "formatting" to summary as suggested.
Today while commenting on moving over to OOo, it was raised that lack of Reveal Codes is an issue that is causing the move to be questioned. I notice that many people that are "Pro Styles" have not worked with RC so don't understand the usefulness of this tool. I have used Styles and in many cases, they can be very useful but in many cases, Styles can be a serious pain. Of course I have to have the time to learn how to make fine grain adjustments to the needed style to meet my needs on a particular document. I came across an analogy for RC over Styles or along with Styles. When editting a photo, sometimes a tool that processes the whole photo is great and useful. Some tools give you a finer control over regions of a photo. If you do a repeated procedure over and over, a script can be written to save time and energy. But if you only need to make small changes that are slightly different in each photo, you won't write a script, you will work at a pixel or small region level. This is the same with RC's. RC's give you the ability to make quick small changes without having to write the script to make the changes. It is a pain to be making a one-of document, only to find that you have to create or edit a style to get the correct formatting for two lines out of 7 pages. Another point about reveal codes is you can find hidden formatting that is affecting you printing or importing a document. I have had cases where I have imported a document only to find that I cannot change the formatting to get the document to work in OOo because I cannot find the code that is causing my problem in an "EASY" manner as with reveal codes. I tried Ian Laurenson's macros but had problems installing them in OOo 2.0b. I will keep trying. Now to learn macro editting. FWIW, one happy convert from Word to OOo because of MS's autoformatting headaches but they want reveal codes.
Allow the reveal codes to show style information. Lots of old word perfect users liked this a lot. Count styles as their own formatting. Reveal styles, both paragraph and character; don't detail the styles in the reveal codes. Reveal formatting where formatting is applied raw. This was requested of me personally, and I found it's been requested before. It's a popular bug, look at the votes.
Lack of reveal codes is also a deal killer for many would be users. I know of one person that has used OOo and loves it, except for RC. It is like a tool that you use everyday. Lose it and you feel totally lost or useless. When it comes to formatting problems, OOo is better than MS Word but worse than WordPerfect.
*** Issue 62817 has been marked as a duplicate of this issue. ***
From the discussion about Reveal Codes on the Users mail list I have some thoughts to add. As all the formatting properties are stored as styles tokens (T1-Tx) in the content.xml, and thus must be in memory, make this information available in a simple dialog. As one user suggested, a properties map that reveals the various styles and formatting properties used at the cursor location would be a great help. I feel that this would be almost as good as reveal codes. Moving the cursor could indicate where a formatting property changes. Add the ability to change or delete properties within this pop-up box and now you have a type of reveal codes. Or at least take you to the property that made this change. I know that some info is displayed in various locations but that is a pain. As a test I made a simple document that had some formatting changes and examined the content.xml file to see what happened when I made changes. What I see is a simple way to display all the information about formatting in an easy way. If Jannz's macro can display this info, why not make an integrated tool to do a better job. I also suggest that there be a menu or added feature to show where the formatting makes changes within a document. Selecting View > Non-Printing Characters will show some formatting features. A second choice of showing the formatting (T1-Tx) token positions, would also help. Especially when trying to find that one piece of code that was imported that screwed up your whole document. There is no reason to stick with the answer that this is how they do it in Word so this is how we will do it. I think we need to look at how OOo can be made better. Reveal codes are better for people that do not have total control over all aspects of a document and have to work with multiple sources and formats and hopefully get into a single working format.
Further to the suggestion. After some thinking. Reveal Codes is a way of showing the formatting at a particular location within the document. In OOo, this is the collected formatting of the document that make up the various properties as set by the styles. A properties display box that is similiar to the Styles and Formatting box could solve most of the reveal codes demands. A display box that shows the relevant stlyles used, fonts and font controls in a simple box. A box that allows the cursor to be moved and the dialog updates as the cursor moves. This box then could allow someone to change, remove or edit the style as in the Styles and Formatting box. Now people can say that this feature is already available but not in an easy to use way. Someone could search through their style and formatting box for each and every character location and not find that one point where the formatting is wrecked. My suggestion would be a box that floats or attaches at the bottom or top of the screen. Like the Reveal codes box on WP. In the box would be something like this. ----------------------------------------------------------------- Page style: Index Paragraph style: Contents 4 Character style: Placeholder Frame style: Default Lists style: Default Font: Times new Roman B U I ------------------------------------------------------------------- If the cursor is moved and the font changes due to the Character style, then this information would be quickly seen. ----------------------------------------------------------------- Page style: Index Paragraph style: Contents 4 Character style: Placeholder 2 Frame style: Default Lists style: Default Font: Nimubus Roman B U I ------------------------------------------------------------------- Now the person will know that the formattng change was due to the change in the Character style without having to go through all the various dialogs. A simple indication of where the change is. Now the user could decide to delete, change or modify the style Character style. This dialog must update with the cursor movements. I feel that this dialog box would resolve most of the Reveal Code demands within the framework of how OOo works with documents.
Looking at this XML coding from a test document, I want to expand on the ability to work in the current framework of OOo to create a dialog box similiar to reveal codes. ---- Style defenition. <style:style style:name="T3" style:family="text"><style:text-properties fo:font-style="italic" style:text-underline-style="solid" style:text-underline-width="auto" style:text-underline-color="font-color" style:font-style-asian="italic" style:font-style-complex="italic"/> ------ Location that the style is implemented. <text:span text:style-name="T3">another </text:span> ------- Now if there was an option to reveal the locations of the "span" statements that were live or clickable or with the attributes displayed in a dialog box at the bottom/top of the screen, then most of what those that are requesting Reveal Codes is implemented. The individual style number (T3) could be highlited or indicated in some way. Thus if styles are nested, then users would be able to see them. I think the idea of live icons would be better than the WP of reveal codes as this could show the nesting over a larger span than just a few lines of text. As in the above case, more than the change to italic is supplied within the style defenition.
While 'style sheets' may be fine for Corporations and small businesses who need standardization in documentation and correspondence, I find that for most personal use 'style sheets' are more of a hindrance the help. I've used bothe M$ Word and WP almost forever. Started with WP 5.1 in DOS and used M$Word as a Corporate *must* for many years before retiring. My reports had to be in a standard format and Word fitted that bill. Not many styles to worry about. Now that I have 'free rein' in what I write I do it all in WP, version 12 and still going strong. I can manipulate words, lines, sentences, paragraphs, and pages as I need to without worrying about which style to select. Yes, OO is a great product and I am using the other functions, but not Writer. I've casted my votes for this enhancement.
The whole issue of "reveal codes" has been thoroughly discussed in list "users@openoffice.org" and, I'm sure, in other lists over and over again. Please, let's stop it! What is the matter with us all? I have yet to see someone say: "I am quite satisfied with the way OOo allows the users to control the the formating of documents; nothing should be changed!" There is a general consensus for the development of better (more powerful and easier to use) tools for the the control of the formatting of documents (with or without styles). E.g. «(...)Still, a list containing any formatting at the current cursor position (or applied throughout a selected area or selected areas) would not be unwelcome.(...)» Even though people say: «(...) there are no codes to reveal.», the fact is that formatting codes _can_ be created and shown! The famous Ian Laurenson's "Reveal Codes macro" proves it, and the same proof is obtained by doing Format->Paragraph, for instance! So, my request/suggestion to the people that (knows how to) write code to OOo is: “please, develop a tool that «provides a viewing/editing mode that shows ALL the "hidden" formatting info of a OOo document and in a way that could be changed by a power user.» [jmcruz, Issue 50501] “ And, as a final request: ***** Please, change the summary of this issue to "Show formatting info" to please the folks that say: «How many times must it be said ... there are no codes to reveal.» ***** Many thanks!
Having seen the discussion on the users list recently, I fear that this issue will never go away and will never be satisfactorily implemented for the WP die-hards. At each point in the text of a document, the appearance is defined by a _set_ of attributes (font, colour, language, margins, indentation, background colour etc.) As I understand it from the comments made, reveal codes indicate how this set is built up by applying them from some default by processing the text from the beginning of the document. In a style-oriented writer, the set of attributes is built up by following the definitions of a style along its parent derivation tree from some default at its root. In effect, each character is given the _whole_set_ of attributes at the _same_time_, and that set is called its style (simplifying wildly). These two approaches are so different, that just writing a translator from one form to the other must be a challenging exercise. Asking either to look like the other in the GUI seems inappropriate if not actually technically infeasible. I can see the way that people are using reveal codes, and that imported text can mess things up, and so there is a need to see where an attribute last appeared. The equivalent in OOo would be to discover where in the style tree a particular attribute was last given its value. The current values can be seen by looking at the current style definition, but it is not easy to check up the tree for a given attribute (say language, or italic, etc.) But the need would be for a tree description _per_attribute_; trying to show it for all attributes simultaneously would be an excessive amount of information. An alternative would be to have on all tabs in the style dialogs a button that jumped immediately to the parent so the differences can be seen. I am not an OOo developer so what I say should be taken with the appropriate grain of salt. But my guess is that trying to display anything resembling reveal codes is not worth the effort that would have to be put into it, and will be a drain on maintenance activity and testing forever. But an improvement in the dialogs showing how an attribute came to be applied by explicitly displaying the tree might be possible. Please correct any misconceptions I might have.
I have read and re-read the styles documents for OOo and I still feel that a tool to provide a Reveal Codes type of interface for the styles would be a handy tool, even when using styles. In the Users discussion, it was brought up that you can sometimes notice code changes when looking at View > Non-printing characters. This is true but raises the question, if styles are so good and perfect at controlling the formatting, why would you need to view any non-printing characters? But that is another discussion. This is one reason why I feel that there should be a View > Styles location tool. I will be uploading a sample document that I created two images from. The first image is of JannzRevealCode macro. What this show is a good representation of WP reveal codes but doesn't reflect the styles that are present within the document. The second image is the sample document with added graphics representing the idea of "View > Formatting points" showing where the formatting changes and the type of style being applied. I didn't get to complicated due to time. At the bottom is a dialog box that displays the styles being used with the particular defenition from the content.xml file from where the cursor is placed within "formatting". Now if you look at the line inbetween Para1 and Para2, you will notice that there is a text formatting. This formatting expands over a single character (space). It is little things like this that can cause problems for people doing allot of cutting and pasting between different documents and types of documents. Added info from OOo documents. ---- From Introduction to Styles. Page 25 Migrating to character styles. Never mix character styles and manual formatting. Manual formatting supersedes character styles. If you combine them, you may end up wasting hours in frustration trying to figure out why your characters styles don't work. --- This raises the question if OOo recommends the direct formatting should not be used, why are the direct formatting buttons provided in the menu bar? -- From Working with Styles Page 2 Many people manually format paragraphs, words, tables, page layouts, and other parts of their documents without paying any attention to styles. They are used to writing documents according to physical attributes. --------- This is exactly the reason why this discussion will continue. Direct formatting tools are provided and thus the situation of mixed formatting can create headaches. OOo provides a tool to make a mess of styles by default. ------- I have used styles and in many cases I will use them. But many times styles are not necssary for the type of work I do. I need to make minor changes to a document that has been imported into OOo from another source.
Created attachment 35622 [details] ODT document for my last post.
Created attachment 35623 [details] Screen Capture of Jannz Reveal Code for reference.
Created attachment 35624 [details] A "View > Styles Location" idea graphic.
As this affects all OS's, I feel that the OS should be changed from "Windows 2000" to "all". I am working with either Linux or OS-X.
As an editor who has used the WordPerfect reveal codes function since it was launched I find it very useful and it prevented me moving to any other word processor. It is only because of a move to Linux that I am now using Open Office - and I really miss the reveal codes! I receive a lot of manuscripts from authors and need to be able to see the codes. But a problem is that many people who have never used WordPerfect have an incorrect impression of what the function is. It is not like looking inside the workings of the file and seeing a lot of source code or similar. Instead we see tags, such as an italics tag or bold tag. OOo people keep saying to use Stylist but that does not do the job. We are not talking here about styles but about viewing tags showing the presence of formatting - they might also show the presence of styles but they must reveal all formatting. It's more like looking at an HTML file but in a user-friendly way. Having the WP type of reveal codes in OOo would help bring in a lot of professional word processor users who hate MS Word and love WordPerfect!
Why has an issue with so much votes no target set?
I see this as a battle between those that find Styles to be the best and those that find Reveal Codes better. I find that Styles are nice and I do use them now that I am learning but I also find there are times that Reveal Codes would be a life saver. I believe that the inclusion of both would be a draw to those organizations that are WP based to OOo. Moving from Reveal Codes to Styles is no easy task. Finding ways of fixing weird formatting problems on imported or merged documents can be almost impossible without Reveal Codes. I know many that still use WordPerfect today in an organization that is almost exclusivly Word. Some are even moving to LaTeX over Word due to formatting issues.
I completely disagree with it being a battle between Styles and Reveal codes. It's not that at all. Using either one of them enhances the use of the other. I always use them both simultaneously. Styles are extremely useful in their rightful place, but a Reveal Codes feature can also always useful. In other words, Styles are not the right solution just to bold a single word; but I do use Reveal Codes to verify that the Bold On/Off codes are in the right place, for example, before a CR/LF or line break. I use Reveal Codes to help me see the Styles codes as well as any other code. Styles are used to group formatting codes together and reuse them for consistency. Editing a Style will change the formatting throughout the document where that Style is applied. Reveal Codes helps in troubleshooting to make sure all codes, including Styles, are placed correctly. These two features complement one another, but they in no way battle against each other. Yes, Reveal Codes should be added to OOO! Give me the control over my own document and allow me to place the codes where I want them, just as WordPerfect does. All it is, is like an HTML-code view of the document, so I can see where to put the opening and closing tags. It's THE standard for HTML, so why not in OOO? Can you imagine the adoption rate of the app when this feature is added?
I've been watching this topic for some time. What I've noticed is that the WP proponents haven't mentioned that WP has styles functionality (at least comparable to Word) - that is until erics mentioned that the Styles & RC are complimentary rather than opponents. I was using styles extensively since the mid 90's, but can't imagine that I would like to not use RC as well. OOo pleasantly surprised me by including a more controllable & comprehensive styles function, but I still miss the reveal codes - here's the reasons: 1. Doing a copy & paste between documents (or even within the same document) you could easily select the text and miss an (or more) opening and / or closing format tag(s). When you now paste at a new position - this could cause format corruption. Try finding the "offending" (or rather half-done) code becomes a pain - especially if you've copied a large amount of text & graphics. 2. As mentioned in a previous post - you could remove the formatting & then re-do. Unfortunately this is a total waste of time, as the formatting could take much more out of your busy day than finding the offending tag & deleting / editing it. I.e. instead of removing all formatting & redoing - just repair the error - usually one or two tags, whereas redoing could become hundreds of user operations. 3. Has anyone ever tried adding text after a formatting end (say after a bold word)? With RC you can position the cursor to exactly where you want so that the bold is continued or not as per your desire - not the program's. 4. Creating page-breaks could cause formatting past the next page ... this I've found happens very often when using styles. Say you've got a Heading3 style on the first line of the next page. Whether the style itself places a page-break or you do it manually - OOo nearly always makes the last line on the current page also Heading3, and it's very difficult to remove. If you don't remove this Formatting you will then always end up with a large blank line at the end of the page - usually not a problem, but when you want to even out your pages this causes hassles. With WP's RC I could place the page-break exactly before the Heading3 tag & all this would be sorted. 5. The biggest pro for RC to me, was the RC inside the style editor - as here you could place the formatting codes for that style in the correct order - as per the page-break in the previous point. In OOo you don't have that type of control.
Just come accross another problem in this regard. I've got a Heading2 as the first "paragraph" (or line) of a page. Included in this heading is an image (anchored to paragraph & right justified). Now I want to insert a new page just before the current one. So I move the cursor to the very begining of the paragraph & press CTRL-ENTER ... oh-no the image stays on the previous page - it doesn't move with the text. Ok ... ok I know I had to tell it to "follow text" in the image properties dialog. But with WP I could position the cursor just before the image tag in the RC box & press CTRL-ENTER, even if the image was not set to "move with paragraph". If I've just moved the cursor to the start of the paragraph the same behaviour would have occured. I.e. the RC gives a quick & easy way of overriding the default image anchor operation. If you want to move the image just this once in OOo, you'll have to check the "Follow text flow" box first then modify your text & then change it back - or you'll have to move the image seperately.
Codes were the best thing ever, and it is what made WordPerfect one of the best word processors of all time. I still use it when possible, and it reminds me of the limitations of OpenOffice Writer. Codes allow the user much more power and contol over documents. They prevent "mysterious" documents- you can tell exactly what is happening. Even trying to determine which styles are in effect on something can be a challenge. This issue was opened almost five years ago.... and still marked as "OOLater". Isn't it time to consider that now is later? OpenOffice is great, but it can always be better!
I agree wholeheartedly. If OOo is simply a replacement for MS Office, then fine you're just about there - you've got most of MS functionality and then some. But if you realy want to be top of the Office packages, then you'll have to look at others as well - MS never was the best and they're still a long way behind most (especially WP). Even since the DOS days (when Borland was still making WP 1980's) the reveal codes feature was there, as was styles, table generation, macros, autocorrect, gramatik check, phrase & paragraph libraries, built-in metafile / graphics editor, etc. etc. MS at present still falls short on some of these concepts which is more than 20 years old - e.g. its Graphics editor is a joke (fortunately OOo has a true graphics editor in addition to the MS like "objects").
*** Issue 74332 has been marked as a duplicate of this issue. ***
Even MS Word is here ahaead of writer! Word shows hard formattings next to the style name. Have a look at the atatched screenshot "Word_2003.png": "Standard + 8 pt"
Even MS Word is here ahead of writer! Word shows hard formattings next to the style name. Have a look at the atatched screenshot "Word_2003.png": "Standard + 8 pt"
Created attachment 42897 [details] Word_2003.png
But implementing a real reveal code feature like WP has is the better solution than Word.
Yes, the Word "Standard + 8pt" in the font drop-down shows you what's cooking, OOo does this as well - just using 3 drop downs (Style, Font & Fontsize). The only difference is it doesn't show how the current formatting differs from the style, as Word does (everything after the plus is an override). This is done expertly with WP-RC as you can see where the standard style begins & ends, and all formatting overrides to any portion of text and / or graphics in between those tags, i.e. the 8pt overrides begin & end tags. So you can see if your 8pt override goes to the next line or the next space or the next word or hafway into the next word (etc etc). If you want to start / stop the override somewhere else - you click & drag. With Word / Writer you have to play around with selcting the text properly, and even then the formatting doesn't always do what you expect. For example you will not be able to see where a graphic has been inserted - so deleting some text may also (unexpectedly) delete the graphic.
Imeb, you point out the key reason for "reveal codes." Know exactly where to insert the cursor for editing and formatting. Not a big issue if you create your own documents from start to finish, but a real pain when having to edit multiple source documents created on different computers and combined into one document. Even the indication of where the style changes would be better than anything available now. As you state, it is easy to delete a graphic just because you are deleting some text that happened to include the insertion point for the graphic.
*** Issue 81267 has been marked as a duplicate of this issue. ***
Because styles are the backbone of OOo and because manual formatting can seem to break them all to easily, it's very important to be able to see the formatting that's in use, especially when the work comes from someone else.
Well, it has been over two years since I made my first post to this thread. I have learned more about styles and I still feel that Reveal Codes is necessary. I still have documents where the styles are mangled or others have not used styles or other general formatting tools but direct formatting. What a pain to edit and try to duplicate the formatting over the whole document.
That's the whole point - using Styles makes it much simpler to ensure consistent formatting, but it doesn't make it easier to format an inconsistent document. If you've got parts of the doc from others, you may find that they've not used styles or created their own styles. Thus at present the most effective way would be to remove all formatting in the inconsistent portions & redo the formatting from scratch (preferably using styles), maybe using the Paste Special (Ctrl+Shift+V) --> Unformatted text and then format as needed. The problem comes in with the "portion" as pasting something into an existing document does not always place the "wrong" formats in the exact position. This is where RC can help. One of the previous posts, said that it's very difficult to implement this as OOo formats each character instead of having opening & closing tags for each format element - uhhh WRONG - you're using an XML based file format, XML works much the same way as HTML: which uses opening & closing tags to show: "bold starts here"some text"bold ends here" further text saved as <b>some text</b> further text It does not save as: <b>s<b>o<b>m<b>e<b> <b>t<b>e<b>x<b>t further text This is exactly the same way that WP RC works - it just shows those open and close tags as graphical buttons so you can click on them to open a relevant formatting dialog, drag them to a new place & delete them if not wanted. When it comes to styles, in OOo's ODF (XML based file) each style is saved similar to HTML's cascading style sheets (CSS) at the beginning of the file. Then any portion of the document using this style has again an open & close tag to show where the style is applied to.
I'm very sad to see that this feature is not receiving the attention that it deserves. There is a HUGE falacy of composition in the threads/arguments above. The argument runs something like this -- because styles are styles, therefore all understanding of the code that frames the layout and changes the format is useless. Styles are styles. They are a great convenience, but they have NOTHING WHATSOEVER to do with the justification of Reveal Codes as a valuable feature. Neither one can act as a substitute for, or reason for the extermination of, the other. They are unrelated featers. (The efficiency and long-lasting impacts of the Madison Avenue brainwashing job that MS underwrote for competition purposes, to trick people into believing that because theiz have "da Styles" dherefores theiz dussunt need "da Codes," when the two features are totally unrelated, still amazes me.) A coder writing php and html gets to see his code (doh!). Why does he need to see his code -- he is writing for one of the most forgiving of display-delivery devices, the monitor. An author using Writer is preparing to send a high precision document to a high precision printer, which is by comparison several orders of magnitude less forgiving than a monitor. Imagine an author using a TeX editor (TeX uses styles!) but his TeX editor refuses to allow him to see the codes which control the layout of his or her document. Two authors, one using MS Word and the other using a TeX variant, are sending their documents to similar printers, and both should have equal access to the layout structure for their documents. One cannot proofread a precise document and rely on "styles" and a WYTYSINWYG monitor. Having sexy styles, or not having sexy styles, will not change that. **Nor will Reveal Codes -- until the inevitalbe problems show up. When there are problems with a PRECISION document (not a Post-It note) at the printing phase, Reveal Codes is the only feature that will help cure the problem. That's part of the learning curve, and that when the author realizes that having access to Reveal Codes helps him or her keep the problems out of the code in the first place, so my sentense at ** above was an intentional lie. Reveal Codes flattens the learning curve and that increases the precision and control. IMHO, Writer should be not be marketed as, or known as, a "Post-It Note" scribbler like MS Word. (And that is just exactly what Word is, with its 10,000 styles and its totally blindfolded authors.) Marketing staff for OpenOffice should "shape" the ooWriter produce so that it develops a reputation as a **precision document** program -- a program that offers the author precise qand full control over placement of all format changes and layout changes. Thus, when an author needs more control than offered by a "Styles-and-Blindfolds" product like MS Word, but doesn't want the learning curve and hassles of TeX, then in the marketplace, then the first product that springs into their minds should be ooWriter. "ooWriter ... the powers of TeX, without the hassles ..." (Of course, everyone realizes that power, without control, is just plain dangerous, wasteful and stupid.) That will require that programmers understand that Styles and Reveal Codes are completely unrelated features. (If they are related, they are only in the sense that each feature augments the powers of the other feature.) And yes, TeX uses styles. But, just because TeX has styles, it's programmers understood MS-BS was not sufficient reason to then hide the code. OpenOffice Writer ... the powers of TeX without the hassles ...
I'm 100% in agreement with bertram. This issue is the main reason that I have reverted to Word Perfect. WP always has had control of the document right down to individual characters. No problem in formating just the way you want, when you want.
Bertram, Well put. I wish I could have explained it that way. I doubt that it will make any difference to the mind set. I would just like a way to know how a certain change occurs within a document and to know which style is the cause. Or is it direct formatting that is done outside the style.
Hello All The reveal codes function should not only reveal the formating codes, but allow the user select them, change them and copy and paste them. Of course I'm not sure about the difficulties involved in implementing this feature, but it would make OOO Writer a much better word processing software than it is now. I see that there is some discussion about styles making the reveal codes feature not needed. Also, there are some arguments that "direct coding" of formating codes could make room for "bad uses" of formating codes. However, for the former argument, it is easy to see that if one does not like to see the formating codes, he or she can continue to work without them. The second argument is not very sound either. What is the best way of correcting a messed up HTML page? It is getting to see the html code! What this post is about, anyway, is about not only having the ability to see the formating codes, but to alter them! Copy & paste too. You can copy a complicated style and then click on parts of it to edit (by the way of menus) or to delete or add or whatever... Thanks for just reading this suggestion. Regards, Luis f. Soeiro
soeiro I partially agree with you but any way of showing the points that formatting, either by styles or by direct encoding would be great. Since my last comment, I have have been reading with great interest about the Open Document Foundation and their dropping support for ODF. One of the comments that I read is about the filters used between documents. If a Style or Format isn't understood by the filter, it can just be dropped. This makes sense from my experience. Now if the filter decides that it is going to drop some formatting from that imported document, some of the formatting that was inside the document could be left hanging. Now I agree that formatting should be available in OOo reveal codes, I have grown to like styles for 95% of what I create. Revealing the coding point would be a great improvement, especially when importing documents from some other editor. I look at revealing the code as being a great compromise. Now to add in the editing abilities will create it's own headaches. The biggest issue on this is the different domains of those that prefer reveal codes and those that prefer styles. From my experience with WordPerfect is that it does have a version of styles in it. Now I think and will repeat that adding Reveal Codes to OOo would make it much better than Word for most home users. Styles takes some time to learn. Most home users want and use a word processing program for those one-time documents and will never need or use have the tools of styles. Shouldn't these peoples needs be addressed? My wife who writes a lot prefers reveal codes. Is smart and has read the Styles guides, still wants Reveal Codes. What she writes today will be formatted differently than what she writes tomorrow. I like styles because I can quickly format or reformat a document that I have created. This is where styles rule. I hate styles when I have to import a document that has formatting that I do not know anything about. Now I have to find every location that the formatting has occurred. Removing all formatting and then using styles is not an option. Someday I hope that this will go beyond this discussion.
"different domains of those that prefer reveal codes and those that prefer styles" That's simply because those (from the different domains) don't understand that the 2 things are separate & complimentary. If you've used WP's styles you'd see that they even implement the RC inside the styles editor. This I've used to make those table of contents (etc.) work properly, as you sometimes find (in WP) that the bold or font size gets brought with the heading. With the styles editor's RC you can place the TOC Open marker just after the formatting & the TOC Close marker just after the text - so only the text gets copied to the TOC. True, OOo doesn't need this particular scenario as it never copies the formating to the TOC & the TOC gets formatted separately. But, wouldn't it be great if you could make a thing work EXACTLY the way you intend, instead of this hit-and-mis approach? "What she writes today will be formatted differently than what she writes tomorrow" Yes and with Styles it would be a simple change to reformat an existing document. RC would not make you work more efficiently if you are reformatting from scratch, except that it would show you where there are erroneous formatting. Where RC REALLY helps is when you've got several docs combined or starting from a corruptly formatted document. "Styles takes some time to learn. Most home users want and use a word processing program for those one-time documents and will never need or use have the tools of styles. Shouldn't these peoples needs be addressed?" Uhhmmmm ... if they don't use styles because it's just a once off thing, I think they're not really power-users and thus wouldn't even know of RC. "Removing all formatting and then using styles is not an option." I agree, it is simply a waste of time. Unfortunately this is the only method of getting rid of "nearly" all formatting errors in OOo. If you combine the use of Styles & RC in WP you see that this type of thing becomes a breeze in comparison. If you only use one or the other (Style or RC) you're not making it that much easier for yourself. "The reveal codes function should not only reveal the formating codes, but allow the user select them, change them and copy and paste them." Yes! In total agreement there. Having just a code viewer is probably better than what's available know, but it would be like aiming for the outside ring on the target instead of trying for a bull's eye.
If you want MS Word to continue to rule the world, don't implement this feature. Then ooWriter can stay the "pretty much like MS Word free alternative." If you want to cut into MS market share, add reveal codes.
Yep, exactly. As I've said before: "If you simply want to replace Word, then you're pretty much there." With this feature you'd probably also gain customer base from the WordPerfect market, smaller but much more demanding - these are usually the guys writing moderate to large documents - not those just looking for a Post-It note writer, or typing one letter every 3 months. If this feature is implemented decently you may even "steal" some of the TeX clientèle. Then if you can get incorporation between Writer, Draw AND RC you may even find that the less demanding PageMaker (or similar) users would start to adopt OOo instead. Yes, well maybe they'd rather go to Scribus. All that said, the 1st step would be to at least reveal the codes. This would make it better than Word (at least in my opinion). Thereafter start implementing something like "Revise" Codes - thus making that code viewer interactive like WP does. You may even find (or invent) something better, but I'd advise starting from WP's RC as a benchmark to aim for. I've come across something that works similarly in a Draw alternative: Inkscape which uses SVG files, allows every single object (line, text, curve, etc.) to be selected and it's SVG code can be opened in a text editor for tweaking. Now given, your user then needs to know how to work with SVG (or in Writer's case XML - similar but different) this might be a step forward. I.e. extract the portion surrounding the current cursor position from the XML file(s). All you then have to do is implement a more user friendly interface.
Created attachment 49513 [details] Example of WP's RC
It would be nice if you haven't voted for this issue to vote for it. It was in the top ten issues voted on in 2003 we have now dropped down to the 23rd. Which is not bad considering all the issues that are out there but keeping it in the top ten would help give it some priority. It says that it has been started but I haven't seen much in the way of it being worked (as far as communication from the devs in comments in this area). I really hope it makes it into OO someday and is on par with Word Perfect.
I'm a home user of Word Perfect & have been since WP first came out, many years ago. I once also used M$ OFFICE. It is no longer on my computer. Since version 1.x of OO I've used that for files given to me from M$. I do not use the writer. Why? Because each and every one of my documents including letters is not the same, except for the letter head. I want control down to the individual character as I get in WP and that includes being able to see the 'reveal code' function. So - I stay with WP for my own work and OO for looking at other's works in M$. And Yes, I have voted for this issue quite a while back.
Sun seems to give other features that address the average word user more priority since this may be a bigger market for StarOffice than advanced users ...
Today I was talking to a WordPerfect user that won't use OOo without a reveal codes like feature. Again the issue of styles and how they work is not the way that WordPerfect users want to work. This conversation started due to major problems with Windows and his thought of moving to Linux. I at least convinced him to load OOo onto his computer and try it for all the other features.
I wonder why "reveal codes" rings only "formatting" bell. Reveal codes is not only about formatting/attributes -- it is about fast (_fast_) way of editing for power-users (please change the component to editing). Let's say you inserted ten formulas like this (latex syntax): A_i = a_{ij} "of course" with OOW in main document you see formulas (the visual effect, not the code). Now, please, replace (fast) all "i" indices to "k". In OOW it is an ordeal. So I don't think it is something with low priority, it is very important feature -- otherwise you narrow down your user base to weekend users and 1-2 pages documents. With bigger document I had to give up with OOW -- I'll cry using latex but I have no other choice -- it is the only way I can make global changes to anything: formulas, attributes, you name it. In OOW I have to click on thousands of objects, patiently select property, change it -- this is not task for humans...
As of today the issue is back up in the top 13. It has been started for a long time. I am just wondering what the status of this issue is? It has been over 6 years since this has been submitted and has been one of the most voted on issues of OpenOffice. I just hope it is being worked on and the reason it is taking so long is that they are doing it right. (Works like WordPerfect).
I think this will sit on the "OOo Later" list for a long time. Many of the developers over the years have always stated "Learn Styles." While I have learned styles and found them useful, they are not the same as Reveal Codes and not as powerful for editing documents that are not created with styles or imported. As more people around work here are using LaTex for the same reasons macias states, it is important to know the customer base. There is a large base that need the find editing control that styles doesn't provide. The control that sometimes is more associated with a desktop publishing program. On documents that I create, styles are great. On documents that I don't create, many have no styles and the formatting is not my option to change to styles.
I agree with mestech. José
"Many of the developers over the years have always stated 'Learn Styles.'" Yet again, they simply DON'T UNDERSTAND what RC is all about. This statement is similar in saying: "There shouldn't be a table object in Writer, since you can copy a Calc spreadsheet into it." I've used WP a lot in the past, and always this keeps bugging me when using OOo. I'm using Styles ad infinitum, but I'm still missing RC. RC didn't replace Styles for me in WP either - I used both in all documents in WP. (See the example I've posted last year). The 2 are NOT Either Or - they complement each other. I'm still finding that WP's old Styles were easier (and more efficient) to use and / or modify than OOW's - simply because of RC. And yes, that thing about search & replace elements in formulas also makes RC so much more than OOw could ever achieve without it. You can even S&R format codes in a document: e.g. to change a individually formatted doc into a Style formatted doc you could use S&R to change say <font size=18><bold>*</bold></font> into <style name=Heading1>*</style> in one step, which would catch nearly all the instances, then you only have to look for those headings not formatted consistently. To developers saying use "Styles instead", I'd metaphor this statement thus: Create a program using only a text editor without tabs / line returns. You can't have a syntax highlighting, auto formatting & auto-complete editor because you should only copy-n-paste from existing code. Why do you want to see your code in a logical structured way? The compiler doesn't notice the difference, why should you? For that matter, why even have a 3rd gen language, you could have done the same using Assembly, or even straight bit code. Don't ask us to make your life simpler, use what we gave you and stop complaining.
I've read through nearly seven years of comments on this issue, and I don't understand the continued resistance to a Reveal Codes feature. Apparently many of the opponents to this feature: A) do not understand how the WP RC window functioned, and B) don't often have to deal with legacy documents. A) The WP Reveal Codes window was not a "license to kill codes." WP used--encouraged--styles just as OOo Writer does, although they weren't as sophisticated. You could, for instance, create a "quoted passage" style that inset the margins and changed the font, then apply it to whole sections of a document. In the RC window, there would appear a single tag for [Style On:Quoted] and another for [Style Off:Quoted]. You could not tweak the formatting within the style; you could only delete the [Style On] or [Style Off] tag (which automatically deleted the mated tag as well). If you wanted to override the style formatting in any way, you had to insert additional formatting--just as you do in Writer. (Yes, you could nest styles.) And if you deleted the [Style] tags, any other formatting tags remained in place, and remained in effect. RC did not replace styles and RC did not conflict with styles. In fact, RC made styles _easier _to _use_ for less technical people, because RC enabled you to see exactly what styles were applied, exactly where they started and ended, and exactly how they overlapped and interacted (or conflicted). B) I have a 200,000 word document in WP5.1 format. It has about 1200 occurrences of what Writer calls "character formatting". I would _like_ to convert it to something a bit more modern. When I convert it into Writer, neither of two things happens: The base font of the original is _not_ applied to the Default style in Writer, and the Default style in Writer is _not_ applied to the converted text. Instead, an invisible internal style is applied individually to every paragraph. (At least, that's the best I can figure out--I'm not experienced with XML.) The base font--the root formatting setting of the whole document!--is converted incorrectly. And I can't find a sensible way to fix it. Opponents to Reveal Codes would apparently have me believe the sensible thing to do is apply Default Formatting to the whole document, then manually reapply 1200 "character styles". If I'm understanding the XML code, it appears that all I really need to do is modify--or destroy--one hidden text style to fix my font problem. But the style in question doesn't seem to appear in the F11 Styles window, and I can't figure out how to modify it otherwise. A Reveal Codes window would (hopefully) offer me an approach to cleaning up such massive conversion problems without all of the manual reformatting required at present. Or, for the more sophisticated user, would make it easier to write a macro to automate the necessary corrections. ----- I quit using MS Word altogether because of its secrecy about formatting. All my documentation at work (dozens of documents) is now done in manually-coded HTML with external CSS stylesheets--because I find it easier to maintain! So far, I've not seen anything to recommend OOo Writer over MS Word except the price. The continued resistance to Reveal Codes implies that the developers don't want Writer to be anything more than a Word clone. Frankly, that's just not good enough for me.
Hear! Hear! Until Writer has a decent RC-like feature (not simply an add-on to display codes) it's (just like Word) a dinky-toy word processor. Just barely enough to write those office memos, but don't try doing anything serious like writing a product manual - you'll be wasting your time. I've also started writing most of these things in HTML. I've been using NVU for that since you can swap easily between WYSIWYG and Source editing (exactly as you'd expect from RC), and have a built in CSS editor. And BTW if you're doing HTML hard coding, XML shouldn't be that steep a learning curve ... they're basically the same structure, XML's just got some extras and more strict (similar to XHTML).
I fully agree with fortran_iv: I also do not understand such resistance to this old request (dream?) of seeing (and hopefully editing) in a better way the formatting styles applied to existing documents. The technical "explanation" that someone has put forward some years ago ("there are no "codes" to reveal) is pure semantics, just like when Clinton said in TV that he "did not have sexual relations with Lewinsky"). This is a sad issue that, as a long time user of Star/OpenOffice, I regret. It would be features such as this that could give OOO another advantage over MSOffice... Will it be so hard to program?... Sorry for not giving my help, but I am not a professional or proficient programmer. José
Here is a poll I created to see just how many would like to see this feature added to OO Writer. http://www.micropoll.com/akira/mpview/530473-134015 Feel free to pass the link around. I bet there are more than 149 people who would like to see this feature added.
Fortran_iv, well said. I use styles and they are great. But there are times that I would love to know what is going wrong with a document that is using styles but isn't working as it should. I don't want to delete all the styles that I have just spent time setting to fix an issue where there is a style change that I cannot seem to select or change. I spent a fair bit of time doing this the other night. I had a style change that seemed to be be related to space or some invisible character. I ended up removing all styles and starting from scratch. I could have saved myself lots of time with Reveal Codes. As I said ages ago, just add it and then OOo will have the best of both worlds.
I am an former WP5.1 user. I understand the discussion and the arguements both for and against this feature (moderne text processing applications are not stream-oriented as was WP5.1), and I suggest that we step back a little bit and realise that the reason this feature was so popular in WP5.1 was not that it made it possible to format without using styles (AFAIR this was called formatting macros in WP5.1). The real reason that this feature was so damn popular in WP5.1 was that it was an easy way to debug your formatting (whether through use of styles or not). It could give you an answer to the question "Why is this text formated this particular way?" Now modern text-processing applications are not stream-oriented as was wp5.1, so "reveal codes" may not really be a good solutions, because there really is no codes in between the characters. There are attributes on characters in stead. Anyway, as ama mentions there really seems to be a general request to show/debug formatting and/or show character attributes in an intuitive way. I suggest, as an alternative to "reveal codes", to reveal this formatting/layout information in a window similar to firebug. Firebug is an extension to firefox, and you can basically click on any content on a html page, and it will tell you the resulting (CSS) formating style, and how this resulting formatting style has been computed through rule of inheritance from parent style classes, etc. Firebug is an excelent tool to format your (X)HTML pages the way you want with or without style. I would like to see similar feature in OOo. If such a feature was there. I would guess that there will only be few WP5.1 die-hards left that would still insist on "reveal codes". I will attach a screenshot of firebug to illustrate my point.
Created attachment 61748 [details] Firebug screenshot, reveals formatting of "50 million downloads!"
> I understand the discussion and the arguements both for and against > this feature ... > I suggest, as an alternative to "reveal codes", to reveal this > formatting/layout information I doubt in first -- otherwise please tell us how your proposition help edit all formulas at once? With reveal codes it is straightforward, but somehow I don't see what formatting has to do with fractions, sigmas, sums, etc. > I would guess > that there will only be few WP5.1 die-hards left that would still > insist on "reveal codes". I am not WP user and reveal codes is not "because we are used to it". Reveal codes is simply useful no matter where do you come from -- why? Read the comments above. Testcase: document with 100 formulas inserted. Replace all Sigma symbols with Theta symbol. Time limit: 5 seconds.
Firebug may be useful for CSS but from the image I can quickly see massive confusion occurring when trying to edit a document. In the suggestion that I presented in 2006 (3 years ago this month), the formatting is indicated within the text of the document. It also provides a description of the nesting. http://www.openoffice.org/nonav/issues/showattachment.cgi/35624/View_Codes.png I have come across so many issues with auto-formatting (styles included) to want to throw the word processor out. There are times I want to know why I get a new blank page in a document when I have deleted all text and still have space at the bottom of the page. Some style but unknown to me where and which one. Styles don't always clear themselves if you delete the text within the style and this can create a surprise formatting issue. It is easy to come up with reasons and examples to prove one or the other argument but if there is a problem that is caused by styles or the wrong usage of styles or some strange conflict, how do you find and fix these? As I have stated so many times. Lets not clone MS Office, lets be better and offer tools that are better. OOo tries to replace MS Office but why not also try to replace WP as well? I know people that purchase WP with each new version because they don't like the way that MS Office takes control of their documents. There are also people that use LaTeX instead of MS Office. This was opened in 2002, I made my first comment in 2005 and four years later, we are still requesting Reveal Codes.
Maybe if we changed the wording of the request from "reveal codes" to "reveal styles" it might get more attention from the devs? It doesn't happen all the time, but often enough to be an issue, where my styles get scrambled or too deeply nested, and I can't figure what's causing my text to appear the way it is. Showing where styles start and end, and what is set in each one would be an enormous help.
> Maybe if we changed the wording of the > request from "reveal codes" to "reveal styles" it might get more > attention from the devs? Or maybe if we implement the feature we could get even more attention? After all, OpenOffice is FLOSS, so everybody can help. Please stop sending those "reminders" -- developers are busy people, reporters are busy people, if you have to just complain reports are aging, please start a your own blog -- this is BTS, it is for technical issues _only_. Thank you for understanding and respecting other people's time.
>this is BTS, it is for technical issues _only_. Posts like this are not only non-constructive, but are truly the thing that "waste other people's time." IE. The time it took me to reply and delete the email from my inbox. This is clearly the forum in which to discuss/debate this enhancement.
I am a strong supporter of this feature. As I child, I learned to write on the computer with Word Perfect. I remember when I discovered the feature how thrilled I was. I also remember when I had to switch to MS Word how inferior I thought it was, due to this feature loss. To this day, every time Word or Writer has some strange error, I lament the loss of that feature. I was NOT a technical user, but found this feature extremely useful. Beyond that, as a child, I felt like it allowed me to learn more about how computers (or at least word processors) work. I do not see the programming problem here for a simple implementation. The system could mirror web browsers "reveal HTML," but with a "save" feature. We can create a new VERY SIMPLE format-free text editor window with the raw XML. The user can hit a "save" button in that window, which will update the Writer window. Or, if that is a problem, Writer could close the document when editing XML, then essentially be able to toggle between them. Not ideal, but certainly much better than unzipping, opening in notepad, etc. An ideal implementation would co-ordinate the two windows with editing possible in both. The reason this issue has so many votes is because people understand its utility. This is the reason so many law offices still use Word Perfect. And to the above discussion of styles, that is a bit of a digression because I would like to see where in the text styles are implemented. The "revert to default" can be useful, but certainly not as good. Please give this issue the attention it deserves.
dkerber, styles are already revealed. The tools to show styles are on the tool bar or the styles box. In this case, terminology is important. The base XML code needs to be displayed to show that there are formatting (not styles) changes. A manually entered bold or underline is not a style, it is a formatting code. It is outside the styles but can be overridden by styles which can make it easy or harder to find problems. Maybe it should be "reveal XML" instead of reveal codes. I will be facing an issue with codes as I will be editing a document that has been written and modified over years between different versions of Office, OpenOffice and Word Perfect. It needs to be re-written and I will be trying to use styles throughout the document. But I need to keep the formatting close to the original (a standard) and incorporate the New company standards. It is on documents like this that I really wish there was a native reveal codes for OOo.
Dear mestech. I completely agree with your comment. My comment with firebug was thought as an inspiration to alternatives to WP reveal codes feature, as I don't think OOo should be either MS office clone, nor WP clone. I can see from your idea graphic that you have had thoughts similar to the features I like about firebug. Personally I have moved from WP to LaTeX (and maybe one day I will move to OOo). Not being able to debug styles and formatting is definitely a show-stopper for me. Jarl
This is just to remind all that the name of this (still) open issue is "Reveal formatting codes". Not just "reveal codes" or "reveal styles"! And those codes can really exist amongst the text characters (and be XML-like or in other format) or just be fictitious (being part of object's attributes, not stream-lined in the text character flow) but, nevertheless, have "real" effects. Whatever the case is (it seems to be the second one), what is asked from the developers is a way to see where, in the text, they are effective (i.e. have formatting consequences).
Created attachment 61891 [details] Example of element / formatting tags for XML
I've attached a screenshot of the oXygen XML editor's method to show element tags. This looks so similar to WP's RC as to be the same, although oXygen formats it using tabs, which IMHO is even better since you can see the various parts easier. However I did a test with the OOo xml based file. I whote the following in a blank ODT: This is a test for formatting. Bolded from start to just after "for", underlined from "test" till end. Opening the CONTENTS.XML file inside the ODT zip archive. The way it's saved makes the RC a bit complicated: <text:p> <text:span text:style-name="T1">This is a</text:span> <text:span text:style-name="T3">test for</text:span> <text:span text:style-name="T2">formatting.</text:span> </text:p> Now each of these "temporary" styles, that should rather be automatically created styles, have the full set of formatting to each: <style:style style:name="T1" style:family="text"> <style:text-properties fo:font-weight="bold" style:font-weight-asian="bold" style:font-weight-complex="bold" /> </style:style> <style:style style:name="T2" style:family="text"> <style:text-properties style:text-underline-style="solid" style:text-underline-width="auto" style:text-underline-color="font-color" /> </style:style> <style:style style:name="T3" style:family="text"> <style:text-properties style:text-underline-style="solid" style:text-underline-width="auto" style:text-underline-color="font-color" fo:font-weight="bold" style:font-weight-asian="bold" style:font-weight-complex="bold" /> </style:style> To have RC working the content should have been saved as such: <text:p><text:span text:style-name="T1">This is a <text:span text:style-name="T2">test for</text:span> formatting.</text:span> However, this would not work properly, since the 1st closing marker </text:span> would close the T2 style (underlining). This is not as intended. So I'm rather then suggesting some visual XML editing to be incorporated into Writer.
I have read through years of discussion about the addition of a Reveal Codes capability to OOo Writer and I have to agree wholeheartedly with fortran_iv (Jan 22, 2009). I am at a loss to understand why so many contributors propose workarounds and other options rather than a full on commitment to make OOo more than just a MS Word lookalike. For several years, I've tried to use MS Word (and OOo), but the limitation of not having RC is prohibitive--I have to create documents in WP then save them to MS Word format to be compatible with my colleagues--I find this still preferable to using OOo or MS Word directly, even with the compatibility issues. My husband is a professor who has to use MS Word due to department regs, but inevitably, I have to convert his documents with WP, fix the accumulated formatting errors (very easy with RC and the "Match Codes" and "Find and Replace" features), then convert back to MS Word. I was so hoping that after finally being able to read WP documents, OOo Writer would have the RC feature and we could dispense with both MS Word and WP. I'm disappointed that it seems unlikely to happen (IMHO, visual XML is definitely NOT the answer).
I also love the RC feature in WP. I'm just saying that now that I've actually looked at the thing myself, I can see no way of implementing it with the current ODF file format. Either they have to change the file format (which is not going to happen), or they implement another form of RC instead of simply cloning WP's version. My suggestion is something in the form of Oxygen XML Editor's visual tags.
Irneb, I agree with your statement. It would be the only way to get around the differences in the technology. As I suggested on 2009 April 27, that maybe this should be changed to "reveal XML" instead of Reveal Code. To indicate that the feature will display the underlying XML of the document. The "Reveal Codes" macro by Ian Laurenson's worked pretty good when I first tried it so many years ago. It looked pretty much like WP's Reveal Codes. Even a simple way of displaying when all the different formatting changes are occurring is a step in the right direction. Like showing non-printing characters as an example. We still have people that are using WP because of this feature. I feel that this is more important than a Ribbon Interface that I read about on my holidays.
After reading on the OOo users mail list about another attack on the use of Reveal Codes, I thought of an idea that may help some of the problems. If there was a macro or tool that could automatically convert all the individual codes that are not styles into various styles and then add them to the documents style list. The macro would have to decide what category the style fit into but it would help. This could go along with the idea of having a "View" option to show where styles are started and stopped.
Is this macro a reveal codes feature? No -- then please open another report. ( And just before you do, do the math -- somebody has to sit down and design such feature, somebody has to write it down, somebody has to spend time on this. Thanks to that macro and time spent, do we get reveal codes sooner or later? So thanks for not reporting anything ).
It is a reveal codes type of feature. Reading through this thread has provided a realization that "Reveal Codes" as per the full request is never going to happen due to the "Only Styles" group the feels the whole world runs better when you use Styles and only Styles. :) To me, Reveal Codes basis in a tool to find and possibly edit the coding involved in a document. One of the main reasons I want Reveal Codes it so find those stupid little formatting issues that occur between different editors on a document when styles (MS and WP versions as well) have not been used. Jannz Reveal Code Macro is a step in the right direction. The idea of a Macro of was to provide a path from the need to Reveal Codes to a method of supporting the Styles only group. I still feel that if the View Non-Printing Characters could be modified to show the various formatting points, it would help a lot. And, this is a discussion on how to implement Reveal Codes. When I logged in today, I thought about how someone my just decide that this is based on an old OS and decide that it should be closed to get rid of it.
And that's why I continue to use Word Perfect as my primary word processing program. I am not in the publishing business, nor do I write novels. Each page I create has a different style, maybe not a great difference, but somewhere in the page will be something out of the ordinary. If I am to switch to OO, there must a way to be completely creative and that definitely means there must be a way to display and edit formatting codes.
It seems possible to at least have a display of what formatting is used, but editing these would not work as WP's RC does. The difference between WP & OOo is that WP uses a form of nested and / or overlapping format codes, while OOo enforces absolutely no nesting and / or overlapping. Each bit of text could only have one single formatting style applied to it. The "bit" may range from a single character, to a paragraph, to the entire document - as long as the format stays consistent to the previous style's format the style is not closed. OOo uses only a sub-set of what I thought it did originally: instead of the formatting codes it only uses CSS-like styles (Cascading Style Sheets), but without the C part (cascading) - so that should probably read SS styles (Style Sheet). Whenever a hard-format change is done to anything, an entirely new auto-style is created. The previous style is stopped and a new style tag is started. The new style incorporates all the formatting codes of the previous style with the exception of the change. This sounds (to me at least) a bit wasted as a simple change to bold would duplicate every other format assignment (font, underline, font size, capitalization, italics, etc.) which is still as previous. However, I can see that it's much more efficient (program speed wise) than WP's nested / overlapping method: see below. WP (on the other hand) has no such thing as auto-generated-styles. It uses open and close tags for each format change. E.g. a bold start & end, an underline start & end, etc. It does have a style start & end tag as well, but this is considered similar to any other format tag pair. This method uses the least amount of space to actually save the formatting, seeing as any one single change is saved as only that change - the formatting which is not changed still continues and is not stopped & duplicated as with OOo. Programming speed wise this could have a detrimental effect though, seeing as displaying any piece of text all the previous text needs to be examined to find out what format is still applicable. With OOo only the latest style start tag needs to be found to display any one piece of text. The reason I can't see OOo using RC directly as WP does is this: OOo has no way of knowing to which style start tag a style stop tag refers. Thus it "assumes" it always refers to the latest style start. This does not create a problem in OOo due to the rule that only one style can be applied at any one time. WP's stop tags are always paired to a start tag (be that a style or other formatting code), thus the stop tag would stop its corresponding style / format and not become confused with something else (like OOo would). @mestech: It would certainly be possible to convert these "temporary" styles to full styles to be displayed in the stylist. It may be a bit difficult to group them into Paragraph, Character, Page, etc. ... but then again maybe not. It doesn't exactly serve the purpose of reveal codes though (only very partly). The real problem I can see with this is an entirely new style is created each time any one thing is changed. I've also not checked if duplicate formatting creates duplicate styles or if the existing (similar) auto style is re-used. This may create hundreds (if not thousands) of styles in the stylist. If you do need the hard-format to be saved as a Style in Stylist, this feature is already implemented (at least in 3.1, probably earlier). If you have the stylist open, select the hard-formatted text. Then click on the "New Style from Selection" button (top-right of stylist panel). Give the new style a name. The group would be the same as the currently displayed style group page (i.e. Paragraph, Character, Frame, Page / List). True this is not automatic, as you suggested for the macro, but at least it's not going to create hundreds of styles which are (nearly) the same to each other.
@mestech (again) :) Maybe that's a step in the right direction: have at least a visual indication of where these Auto-Generated-Styles start / stop. This way some of the RC functionality is possible as the user could at least discover where changes occur, and thus it would make searching for errors a bit easier. Then it would be nice to have something (say in the pop-up menu) to revert to previous format at a start of a newly generated auto-style. This way the user can see: "Oh! Here's where the error happened. Change it to what was previous." And then (what would really be nice) is to have a display list of the previous, current & next auto-style's formatting codes. Preferably highlighting the differences. And then allowing the user to "join them" by removing / adding differences.
@mestech (again) :) Maybe that's a step in the right direction: have at least a visual indication of where these Auto-Generated-Styles start / stop. This way some of the RC functionality is possible as the user could at least discover where changes occur, and thus it would make searching for errors a bit easier. Then it would be nice to have something (say in the pop-up menu) to revert to previous format at a start of a newly generated auto-style. This way the user can see: "Oh! Here's where the error happened. Change it to what was previous." And then (what would really be nice) is to have a display list of the previous, current & next auto-style's formatting codes. Preferably highlighting the differences. And then allowing the user to "join them" by removing / adding differences. In the long run this may even become more usable than RC for fault finding. Then there simply needs to be some way of doing Search & Replace for formatting as well.
I started with WP 5.1, then years later moved briefly to WP10, then quickly to X3. I've been using RC most recently to create templates for things like a recipe template for a 3-ring 8.5 by 11- inch binder (X3 just implemented a usable one) from pre-existing template for a 3 x 5 card. When things don't work exactly as I intend, I can address it point-by-point until it is right. Yes, this is a bit of hybrid-ing my word processor with desk-top publishing features, but that is the level of production-control I prefer. Control that is no longer available on non-Windows systems. The numerous comments that OpenOffice products should be more than clones of the commercially-available resonates with me. I would like to think that the contributors and developers of this project would feel the same. --And WordPerfect could definately use color matching for its matched format tags. A place where we could be better at RC than the RC Masters.--
There are usually some voices against RC feature stating that user should use styles, and modify them, and not tweak this or that attribute. Great, but in real world I don't create documents all the time, very often I download document from the web site (.doc "of course") and I only have to fill the blanks. There is also another reason to have RC -- to see why OOO display document the way it displays, e.g. this huge gap below line in the document I edit right now, is because of: a) the style of the paragraph b) attribute of this paragraph c) table cell settings d) or it is just a bug in OOO, because yesterday there was no gap? Without RC I cannot be sure, so I have to check all the possible settings to get the clue -- it is waste of time.
I think the case for reveal codes was incorrectly stated from the beginning. Reveal codes should present all formatting codes (both styles and direct formatting). This will make styles even easier to use; since reveal codes will also display to user where styles start/end. At the moment, users must move through document one character at a time to see where styles change. If the argument against reveal codes is that users should use styles and not directly format content; then the functionality to format content without using styles should be removed from OOo. Simply force users to only use styles. As long as users are allowed format content outside of styles; a need for reveal codes exists. Someone should change "OS: Win200" to "OS: All".
OK, I'm apologizing up front because this will be harsh and I don't have the time to reread 8 years of duplicated posts to get the details that are buried deep inside: Well, if they strip the functionality to directly format content and force us to use Styles to format anything, then they'll be forcing a lot of people to leave OO.o -- because open source people don't like to be forced into anything. I'm one of them. They'll go find another app with more openness. As I'm aware of the open source arena, that's how open source apps become so popular: they cater to their users and implement highly requested features, of which I'd guess RC is one of the most requested. So forgive me now for being harsh and asking without reading the last 8 years of posts again, but why is this such a big headache and why all the years and years and years of fighting it when it's so requested? What in the world do your users have to do to get a feature implemented? The first bug on this was logged 8 years ago! What does it take? Yes, I know there is an ODF format issue (which wasn't even implemented when the first bug was logged), but what's the problem? Why is it so prohibitive? Why can't styles overlap and nest? And for crying out loud, why do they have to be Styles? (In my book, and for millions of others around the world, a Style is defined as a group of formatting codes, and a tag is a single formatting code.) Why can't they just be simple tags, like [Bold On][Bold Off] and [Underline On][Underline Off]? Millions of people all over the world understand that logic. Check out any HTML editor and you will see they ALL are basically RC editors showing beginning and ending tags allowing them to overlap and nest codes/tags, with or without the document preview. Double click on a tag in the better editors, like Dreamweaver, and it pops up the corresponding dialog for you to edit it; hmmm, just like WP! Do people consider that a copy of WP? Who cares if they do? Really. All HTML editors show the tags, and OO.o will format in HTML, so why all the bru-ha-ha? Just show those codes to start out with and build from there. Show the XML codes and go from there. I'm getting tired of the fight. I've been following this since the beginning. What hasn't been said that will convince the developers it's a good idea to get as close to WP's implementation as possible? It's all been said 400 times already! And frankly, what's wrong with adding highly requested features that are already implemented in commercially available apps? Of course OO.o might, in time, offer more than the commercial apps, but who cares if features are copied? If it works and people want it, put it in. Why reinvent the wheel? Just make the wheel more durable and more functional! Beat them at their own game. But at this rate, nothing will get implemented and we're still where we were 8 years ago when the first RC bug was logged. Now that's open source progress!
This is still the one thing which makes us (my wife and myself) go back to WordPerfect again and again. Styles is not the solution, if anything it makes it worse - at least that is how I felt about styles in Word and for that reason never switched to Word. We are just working on a document which are forcing ourselves to do in OOO as we like to get rid of WP on our machines. Something which would have taken maybe 10 minutes took is an hour or more. I wish I could help implementing something like this but that is way over my head. It looks to me that this will never happen in OOO, so maybe it is time to re-evaluate things (look for alternatives or fork out the money to Corel for an update of WP). Such a pity! Werner
The inability to "reveal codes" is why Open Office has not been adopted in our offices; the head paper shuffler is "old school" & sticks with what she wants, and so goes the rest of the office. I'm running Linux, as do most of us, so we're stuck with using WP running in a virtual machine, which isn't so bad. The Boss here won't make any donations to the Open Office project though because he considers it "unusable" as is.
If you need WP on Linux, you could try Wine - http://appdb.winehq.org/objectManager.php?sClass=application&iId=222 Not all the versions seem to work though, but at least you don't need a 2nd OS in a VM just to run one program. Alternatively (if you don't mind using an older version), there's still a "free" native Linux version of WP8 available: http://tldp.org/FAQ/WordPerfect-Linux-FAQ/downloadwp8.html
Maybe the following 2 links can give a better explanation for those who have never experienced this feature: Getting the most out of Reveal [formatting] Codes in WordPerfect: http://www.corel.com/servlet/Satellite/us/en/Content/1153321168468 "In summary… The Reveal Codes feature gives you unprecedented control over a document's formatting, layout, and structure. Clearly, Reveal Codes are the most powerful tool you have when it comes to troubleshooting a document." The Reveal [formatting] Codes feature in Corel WordPerfect. http://en.wikipedia.org/wiki/WordPerfect "The Reveal Codes feature is a second editing screen that can be toggled open and closed at the bottom of the main editing screen. Text is displayed in Reveal Codes interspersed with tags and the occasional objects, with the tags and objects represented by named tokens. The scheme makes it far easier to untangle coding messes than with styles-based word processors, and object tokens can be clicked with a pointing device to directly open the configuration editor for the particular object type, e.g. clicking on a style token brings up the style editor with the particular style type displayed. WordPerfect users forced to change word processors by employers frequently complain on WordPerfect online forums that they are lost without Reveal Codes."
- Thank you for the links jctbvk. These are informative links to this subject. fbax, the idea of showing all has been discussed many times. I feel that those that push styles as the only way don't understand how many of us work. We don't all create documents that use common styles. In a business setting, I can see it some times. In many cases, you get a document that others have worked on that are not following any style have been direct edited. Their comment is to delete all formatting and start again with styles. Not an option when you are only changing a paragraph from a 30 page document. We don't all have the authority to make the changes. Remove direct formatting. What a thought. Nice way to push many away from OOo but I guess it really is no different than being told to use styles or no formatting. - erics, nice comparison to an HTML editor. I think I looked at that a few years ago. XML formatting is like that. Open and close tags. Heck, the RC was like that from my old WP days. The issue is the divide between those that work on random documents that will be formatted in a unique way. A document that is created for a one time use. A document that would require making it's own unique style that may never be used again. For these one-of documents, direct coding is easier and a time saver. Or those that work with people that use their own formatting between different applications. And those that work in an environment where every document is formatted almost the same. Formatted to some set standard where it is easy to use styles to meet this requirement. This divide won't be resolved unless we all cave and use only one application in the world. MS would like that as it would most likely be their product. --------- I am working on a document now that will be edited by others. They are using WordPerfect, various versions of Word and OOo. I ensure that during the whole phase, there will be a lot of manual formatting implemented. This is going to be a headache if there are any strange issues between the other applications and OOo. I have run into them before and in a couple of cases, iannz RC macro has saved my butt. I will have to try it again with this document. Also something I have come across a couple of situations where I create a document that I have not used any manual settings or styles that I have a problem with. I would like an easy way to know where the problem is. I don't have the time to uncompress the saved file and look at the XML code to figure this out. I would like to see the point where I have a problem. A way to get my cursor into the right point to enter a CR or something else.
The fact that people keep pleading for this feature when about everything that can be said about it has already been said, should tell the OO folks something. So I figure the following: 1. They can't do it. OO may be designed in such a way that they would have to totally redesign the product to implement the feature. However, for someone who is familiar with WP Reveal Codes, that is not too high a price. 2. They don't want to beat MS Word. MS Word has always been lame. It's harder to use and can't do as much as WordPerfect. The only way they could beat WordPerfect was to bundle the their products together and sell them below cost. Their cash cow Windoze allowed them to do that. Now, OO can return the favor, because it literally is free. OO will likely never be 100% compatible with MS Office, because MS will keep tweaking the format. So to win the market they have to be better. Reveal Codes is a key step in getting there. That argument has already been made several times over. So all I can conclude is that they don't want to beat MS Word. So what do we who need Reveal Codes do? 1. We keep using old copies of WordPerfect, which is still better than either MS Word or OO Writer. (I still use WP 5.1 macro-based systems to generate documents because it still works, and I can't duplicate it elsewhere.) 2. If we can't do that, then we use whichever of the equally lame twins (MS Word or OO Writer) we must to get the job done. 3. Maximize your votes (2) for this issue. Hopefully, if it keeps bubbling to the top, it will make it a pain for the OO folks to ignore it.
> So I figure the following: 3. Elegance by obscurity -- RC would reveal to anyone, not even a developer, how OOW manages the attributes. It would be interesting to see the internals of some crazy effects I see when using OOW. Take this hypothesis with a smile ;-) > So what do we who need Reveal Codes do? 4. Collect the money and "hire" a programmer for that. I would pay for this but I would have a guarantee it would not end with taking money and no product, or even with code (good quality) but rejected by OOO team (Not Invented Here Syndrome). I have to buy MS Office anyway (yes, I know, no RC, but OO is not very good in importing .doc files as you probably know), so few bucks more won't kill me (I think). However I have no idea how to setup such hiring.
"4. Collect the money and "hire" a programmer for that. I would pay for this..." We have never had a problem "donating" to open source projects, that option is acceptable, though it would have to be "after the fact" in order to assure the donation is properly applied.
I am not talking about charity -- I am talking about buying this feature. Why this way? Because _I_ am tired of not taking responsibility, of abandoning created software, of ignoring those who paid, of not listening (8 years!). Charity is OK if you want support homeless, poor, etc. But making software is a profession, so if my money will go for a software, then only for a professional programmer, who takes his/her job seriously. > We have never had a problem "donating" to open source projects I can only speak for myself, but I had and I have one and fundamental. I have no problem for paying for good quality product, with solid prospects of reliable development (because I need a tool for a job, not toy for my amusement). "Closed" or "open" (source) does not imply the above (it is orthogonal to the quality).
> "4. Collect the money and "hire" a programmer for that. I would pay for this..." I'm with macias; setup some kind of trust to collect funds; paid to OOo project when code is released in production version. I'd pay! Who is "Assigned to ama"? How much cash is required to get ama to start coding? What to do if funds never reach funding threshold to initiate coding or project is still ignored? Alternate non-profit?
Created attachment 67905 [details] Explanation of RC Alternative
I think this is not going to happen exactly as per WP's RC. Therefore I'm starting to "design" an alternative which could work for OOo. See the attached file - (Explanation of RC Alternative). I'd like to see comments about this as I want to run it by the UX team as well. Maybe I should start a Wiki Page there?
Thank you irneb for your explanation of the differences between WP and OO. I'm a home user of OO and have used WP from DOS versions to X4 (14). And the main reason for using WP is because I have complete control over formatting. I don't need styles as other than a heading on a letter my documents are mostly different from one another. Formatting on the fly - not restricted. So, although I do use OO as a substitute for M$ office (when others send me M$ Office files), I do most of my writing with WP. But I do use OO for spreadsheets and data bases.
Irneb, Very good explanation! Totally agree that OO can't totally duplicate the WP RC feature, as the formatting is done differently in WP (won't go into this here as it not pertinent). What I expect from an "OO RC" feature is to show in a window/frame all the details about the formatting of the document, which I think you have shown very well in your alternative document. Only thing I would like to suggest is not to use special characters for things like Line-Return, Tab, and Page Break. I think they should be special "buttons" (in your terminology), e.g. something like "HRt" and "HPg" "Left Tab", "Right Tab" "HD Back tag" or similar as done in WP. There also needs to be special handling for things like images and other embedded objects. With regards to the temporary styles, there should probably be some way of converting into a permanent style. Werner P.S. We are only two users, but this would be something I would be willing to help funding in the order of 50€ or so.
Interesting comments. I agree with irneb as many of his comments go along with what I have said over the years. Some of your suggestions work closely to what I suggested back in 2006. We think alike. :) -- Now I am working on my document that has been edited on Word and WordPerfect. I was instructed to remove all formatting and start from scratch. This sounded like a great idea. I thought I would follow the suggestions that keep getting told to use RC fans on how to remove formatting. What a good test. Now, I selected the whole document. I went to "Format > Default Formatting" thinking that all formatting would be removed. I was wrong. I still have some sections within the document that I cannot find how they are assigned. I keep getting a status indication for these sections. On the screen I get lines where these sections start/end. I have checked everything and all formatting is listed as default. It is something that can be copied as I have tried to select all text and copy it but the formatting stayed with the text. I have spent over an hour trying to get this out of the document. Reveal codes would have resolved this in a few seconds. It is the only formatting left. I will start looking at this again on Monday. Grumble Grumble.
Word and OO are unhelpful to writers who wish to self publish. Format is hugely important and styles are too constraining. Without reveal codes, it can take hours to get to the root of why something is not formatting correctly. WordPerfect is a joy to use in this respect but it does not install satisfactorily on Linux. Adding a reveal codes facility to OO would make a huge difference to its appeal to self publishing writers. After that, deal with the problem of providing sufficiently flexible arrangements for A5 booklet setting up and printing which is another thing WordPerfect does beautifully.
Happily, WP runs just fine in even a simple virtual machine; we're using the now-discontinued Win4Lin in the office but at home the folks at VirtualBox have been kind enough to allow it's use on personal computers free of charge. If OO ever gets around to implementing the reveal codes feature we'll probably go back to using it, but for now the absence of the feature is a deal breaker.
I'm with you Bob3! Mar 7, 2002 (the first RC bug entered) is a long time ago and too long to beg for a single feature. I have joyfully returned to WordPerfect and upgraded to v.15 without a single regret. WordPerfect is (and always has been) BY FAR the best product out there, bar none. What's more, WordPerfect developers don't require me to convince them that the sky really is blue and grass really is green. I'm tired of depending on the OpenOffice.org product managers and developers who are really taking their marching orders from the behemoth in Redmond, so it seems. Else, why the big fight against their supporters? Open your ears people! As it will soon be said, "OpenOffice who? Is that really still around? Whoever uses that anymore?" That phrase stinks of Novell and many other brands that could have made a deeper mark on society had they pulled their heads out of the sand and listened to their customer base and MADE things work the way their user base wants and needs it to work. Anything is possible if you have good enough developers. Come to think of it, I almost hope OO.o never does incorporate RC now, because that way, OO.o will never steal away the masses from the WordPerfect customer base. Hence, WordPerfect will still have the user base, including me, to continue developing their software and beating the pulp out of their competition. A few bucks for a far-superior product works for me, rather than no bucks for a continuous headache. Good luck. OO.o will use its bucks for aspirin instead, unless they start listening.
As I commented on March 23, 2006, I'm still using Word Perfect 12 for correspondence. Using DataBase and SpreadSheets from OO, but until a WP type interface is forthcoming - I'm staying with WP.
I've been told to look at this as an alternative to wordperfect. I won't use OO unless and until a change is made here.
As a potential new user of OO, I checked for the reveal codes feature, which I use extensively in WordPerfect. I use it for more than repairing global formatting; I frequently import text from elsewhere that has nested italics, subscripts, font sizes, bolding, etc., and I need to know the scope of those features. I don't want to simply have everything revert to plan text ... I want to preserve some features and get rid of others. Also when I'm writing, I use these various formatting codes as well. Styles are completely irrelevant to what I use RC for. I'd happily convert if RC were part of OO. As it is, OO won't be considered further.
It is amazing to me that this request has been here for 10 years and there is no movement. a. Some folks won't use OpenOffice until an equivalent of the Reveal Codes function of WordPerfect is provided. b. Occassionally, folks who understand how OpenOffice is tied to the OpenDocument Format attempt to explain that OpenOffice.org doesn't use "codes" in the manner of the historical WordPerfect format. Its nothing so simple. Stepping back, it is the case that troubleshooting a document might be assisted if there were something comparable to WordPerfect's "Reveal Codes" but appropriate to the use of ODF by OpenOffice-lineage software. I've seen nasty situations where formatting mysteries show up around fonts and styles, for example, and it is very difficult to figure out where a conflict seems to be occuring. (One might be able to figure it out by inspecting the XML of the ODF document, but that is not something expected of even power users of the software.) And, of course, we are talking here about providing such an extensive feature absolutely for free, if one could find someone motivated to build it solely for the satisfaction of it. I have a couple of examples that might at least clarify how different the situations are. I wonder how many more years this request will still be here!
The 2010-02-19 "Explanation of RC Alternative" attachment does explain the situation quite well. It misses the case that ODF <text:span> elements can be nested and that one must somehow deal with inheritance happening in styles. What one needs to know is the style-defined features applicable at any point in the text and, if necessary, where is a particular one of those features (e.g., the applicable font) determined. The comparable situation with [X]HTML is not just the element structure but the application of CSS styles along with addition of CSS-style feature inheritance rules. Even so, I wonder whether availability and use of Iannz RevealCode macro would not work well enough (comment 55 at https://issues.apache.org/ooo/show_bug.cgi?id=3395#c55). Apparently work on that macro was abandoned in 2007 and it would likely have to be redone for OO.o 3.3 and later.
(In reply to comment #155) > Even so, I wonder whether availability and use of Iannz RevealCode macro would > not work well enough (comment 55 at > https://issues.apache.org/ooo/show_bug.cgi?id=3395#c55). Apparently work on > that macro was abandoned in 2007 and it would likely have to be redone for OO.o > 3.3 and later. Here is where Iannz OpenOffice.org work is found: http://homepages.paradise.net.nz/hillview/OOo/ The macro is under LGPL. It appears that there is no version of the RevealCodes macro since 2004.
(In reply to comment #155) > The 2010-02-19 "Explanation of RC Alternative" attachment does explain the > situation quite well. It misses the case that ODF <text:span> elements can be > nested and that one must somehow deal with inheritance happening in styles. > Could you please indicate how to nest these things? Or is it only possible through hacking the XML files? Through my own investigations every change makes a new style (be that a user defined style or an automatic style), but no-where does the ODF implementation allow for nested tags inside the text. If it was possible RC would become a breeze to implement (in comparison to now at least). Unfortunately we're stuck with a decision made a whole lot of years ago, about how the file structure is supposed to be. This probably happened in the SXW days (or even earlier). And that decision was to not use a streaming format such as WPD and HTML does. For various reasons this wasn't a "bad" idea per say, some performance gains are possible through this decision. Unfortunately it makes a RC like feature a near impossibility though. What I can't understand though is why (if you're not going to use nesting in a streamable format) use XML then ... isn't that one of the most Stream-able Nestable file formats out there? Even more so than HTML? Sorry, I'm going off on a tangent ... just curious as to why do one thing and then another which seems so like "incompatible inconsistent thinking". It's as if the decisions were made on an ad-hoc basis without reference of prior decisions. Not that I'm saying XML shouldn't have been used, it's just that it seems it was used solely for the reasons that it was a "open" and "widespread" "standard" ... not because it was the best fit for the intended data structure. To the contrary, it's probably the most removed fit for the ODF data structure. And this thread actually proves it.
(In reply to comment #157) > (In reply to comment #155) > > The 2010-02-19 "Explanation of RC Alternative" attachment does explain the > > situation quite well. It misses the case that ODF <text:span> elements can be > > nested and that one must somehow deal with inheritance happening in styles. > > > Could you please indicate how to nest these things? Or is it only possible > through hacking the XML files? Through my own investigations every change makes > a new style (be that a user defined style or an automatic style), but no-where > does the ODF implementation allow for nested tags inside the text. If it was > possible RC would become a breeze to implement (in comparison to now at least). [ ... ] Let us not confuse how the ODF format is defined versus what any given ODF-supporting producer uses of the format. So long as ODF is properly consumed, it is not necessary for an implementation to produce the same document exactly the same way. (This has potential usability concerns when the document is being worked on collaboratively, but the ODF specification does not address that, just the format.) It is too late to argue the choice of XML and many XML-allied standards as a foundation for the OpenDocument Format. Note that ISO/IEC IS 29500 for OOXML also uses XML and a form of Zip packaging (OPC) as a foundation, although OOXML is more run-oriented than the stricter hierarchical nature of ODF. It is all done with XML though. I find it interesting that OpenOffice.org-lineage programs tend to create flat switching among automatically-created anonymous styles within a paragraph or heading, without any tendency to do <text:span> nesting. That does not mean it is difficult to translate. OpenOffice.org 3.3 accepts WPD files and produces ODT files in its way of styling. WordPerfect X5, I see, accepts the ODT file and after conversion manages to place it in its format structure, as can be seen in the Reveal Codes of the ODT->WPD conversion.
Created attachment 77454 [details] Example of an OpenOffice ODT document (from a WPD) read back into WP and shown with Reveal Codes There are other attachments that show what Reveal Codes is like in WordPerfect. This example is of an OpenOffice ODT document (imported from WPD and saved as ODT) that is opened in WordPerfect X5. Notice that the conversion to WPD is relatively reliable (there was no justification used in the original WPD or the ODT version made from it). Keep in mind that these Reveal Codes are for a document that is now in WPD format, even though it was an OpenOffice ODT document previously converted from a WPD. (The next attachment looks at the other side of the story.) (In reply to comment #154) > I have a couple of examples that might at least clarify how different the > situations are. I wonder how many more years this request will still be here! (In reply to comment #158) > I find it interesting that OpenOffice.org-lineage programs tend to create flat > switching among automatically-created anonymous styles within a paragraph or > heading, without any tendency to do <text:span> nesting. That does not mean it > is difficult to translate. OpenOffice.org 3.3 accepts WPD files and produces > ODT files in its way of styling. WordPerfect X5, I see, accepts the ODT file > and after conversion manages to place it in its format structure, as can be > seen in the Reveal Codes of the ODT->WPD conversion.
Created attachment 77455 [details] Extracts of the ODF document showing how the same text shown in attachment #77454 [details] is formatted in ODF via an OpenOffice-lineage application I should point out that the exercise for making a roundtrip from WPD to ODT to WPD was done using LibreOffice 3.3.2 as the intermediary. It formats ODT output in the same way as all OpenOffice.org 3.x implementations do, including the forthcoming Apache OpenOffice 3.4. There are two parts in the XML specimen. The first, the <office:text> element provides the text of the single paragraph in the document. It is this: <office:text> <text:p text:style-name="P2"> <text:span text:style-name="T4">This little ditty</text:span> <text:span text:style-name="T5"> is simply to see </text:span> <text:span text:style-name="T2">what </text:span> <text:span text:style-name="T1">Reveal Codes</text:span> <text:span text:style-name="T2"> is all </text:span> <text:span text:style-name="T5">about when used in </text:span> <text:span text:style-name="T6">Word</text:span> <text:span text:style-name="T3">Perfect</text:span> <text:span text:style-name="T5">. <text:s/> </text:span> </text:p> </office:text> Notice that, although no specific style was selected with this document, a number of automatic styles are applied based on actions taken by the document author (mainly font selections, bolding, italicizing, and changes of font size). THe different <text:span> elements and their text:style-name attributes appeal to the places where the resulting formatting conditons have been retained. Note that there is an automatic style for the paragraph itself as well. Here is one of the automatic style definitions (all of them are in the attached file). They are all on this pattern: <style:style style:name="T1" style:family="text"> <style:text-properties fo:color="#000000" style:font-name="Courier New" fo:font-size="12pt" fo:font-style="italic" fo:font-weight="bold" style:font-name-asian="Courier New" style:font-size-asian="12pt" style:font-style-asian="italic" style:font-weight-asian="bold" style:font-name-complex="Courier New" style:font-size-complex="12pt" style:font-style-complex="italic" style:font-weight-complex="bold"/> </style:style> These are not done in a way where only the change from the adjacent span is handled, nor are spans nested in a way that has inner spans only identify changes. It is of course possible to synthesize such information -- it was done when the ODT was converted back to a WPD. But it is not how the OpenOffice-lineage engines are designed to reflect certain format changes via introduction of automatic styles that capture them. In addition, for someone working natively with OpenDocument format documents, any kind of Reveal Styling (it is not about codes) would need to be more harmonious with how the format works as well as the different ways the format can be controlled by user actions (i.e., using some sort of Reveal Styling to see where to adjust the document in the editor or in the Reveal Styling interface itself). Having said all of those high-level things, there is also this: There was in the past a macro that managed to do a reasonable job at providing style information about selected text in OpenOffice.org. There is information about that in the comments on this issue. That remains the most-likely-achievable expedient solution and it depends on someone able and willing to recover and continue that work, if not re-invent it. (In reply to comment #154) > I have a couple of examples that might at least clarify how different the > situations are. I wonder how many more years this request will still be here! (In reply to comment #158) > I find it interesting that OpenOffice.org-lineage programs tend to create flat > switching among automatically-created anonymous styles within a paragraph or > heading, without any tendency to do <text:span> nesting. That does not mean it > is difficult to translate. OpenOffice.org 3.3 accepts WPD files and produces > ODT files in its way of styling. WordPerfect X5, I see, accepts the ODT file > and after conversion manages to place it in its format structure, as can be > seen in the Reveal Codes of the ODT->WPD conversion.
I miss this feature too, from my WP days. I am working on an extension, but very slowly. See "Status" at <http://wiki.services.openoffice.org/wiki/User:TJFrazier/Reveal_Codes.>
getting rid of value "enhancement" for field "severity". For enhancement the field "issue type" shall be used.
*** Issue 14694 has been marked as a duplicate of this issue. ***
(In reply to orcmid from comment #160 of 2012-04-17) [ ... ] > In addition, for someone working natively with OpenDocument format > documents, any kind of Reveal Styling (it is not about codes) would need to > be more harmonious with how the format works as well as the different ways > the format can be controlled by user actions (i.e., using some sort of > Reveal Styling to see where to adjust the document in the editor or in the > Reveal Styling interface itself). > > Having said all of those high-level things, there is also this: There was > in the past a macro that managed to do a reasonable job at providing style > information about selected text in OpenOffice.org. There is information > about that in the comments on this issue. That remains the > most-likely-achievable expedient solution and it depends on someone able and > willing to recover and continue that work, if not re-invent it. There has been no activity on this thread since Oliver-Rainer Wittmann's comment of 2012-06-13, although there was a duplicate Issue 14694 in 2014. At this time (2016-02-01) here is no prospect of anything being done that provides the desired functionality in the product. Provision of an extension with some degree of function remains possible but is out-of-scope for the product itself. I am changing this Issue to Resolved - Won't Fix. This issue record will remain and the discussion might be useful for anyone who entertains such functionality (in any ODF-oriented product) in the future. Comments can continue to be made. Interested parties should be clear that there is no likelihood of changes to the software.