RE: CORRECTION: Section Number resets after closing file
Carol, Yes, I have experienced odd things with Document Numbering properties in Frame 12. Like yourself, they seemed a bit transient and hard to pin down. But from time to time working on particular documents, I've definitely seen things such as certain chapter files stubbornly refusing to retain the settings I'd given them in the book (e.g. updating the book would produce repeated protests in the error log that there was a settings mismatch). I seemed to be the sort of thing that taking a deep breath and rebooting cured, after which I couldn't reproduce them. But they happened nonetheless! David. Message: 2 Date: Thu, 03 Jul 2014 11:52:59 -0600 From: Carol J. Elkins celk...@awrittenword.com To: fram...@omsys.com,framers@lists.frameusers.com Subject: CORRECTION: Section Number resets after closing file Message-ID: 20140703175309.57ce920d8a...@miniserver.beyondprint.com Content-Type: text/plain; charset=us-ascii; format=flowed You know, I tested the behavior of the Section number problem on this book three times before I sent the email for help. Then I tested the other five books (and 80 documents) in this series of books and the Section number does not reset when the files are closed and reopened. Then I tested the problem book and now the Section number behavior fine. So I'd like to modify my question: Has anyone experienced any instability in the Document Numbering properties functionality? I have had documents' Chapter number and Volume number mysteriously reset to 1 since upgrading to Frame12. I thought it was probably me having senior moments or perhaps I acidentally imported a book's numbering properties across all files in a book. But ever since this inconsistent behavior started, I've been much more careful to NOT import ANY Document properties in any books. I can't think of any other way that I could have corrupted the Chapter or Section numbers. But the problem is intermittent and unpredicably caused. So other people's experiences might help to build a case. Carol I'm working in Frame 12 fully patched on a Win7 system. For each document in a book, I've set a specific Section number using the file's Numbering Properties (Format--Document--Numbering--Section). Everything works fine while all files in the book are open. Cross-references to that section number work correctly. However, when I close the files in the book and reopen them, the Section number for each file has reset to 1. For each of these files, I've also defined a Chapter number using the same process. The Chapter number does NOT reset when the files are closed are reopened. Can anyone verify this behavior in their Frame12 app? If so, then I'll file a bug report. BTW, is there a way to check to see if someone has already filed a bug report? Carol *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys Limited, which is a company registered in England and Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For a list of European legal entities within the Invensys Group, please select the Legal Entities link at invensys.com. Invensys Limited is owned by the Schneider-Electric Group. You may contact Invensys Limited on +44 (0)20 3155 1200 or e-mail recept...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
FM12: Quirks in Find/replace using RegEx (Perl)
Friends of FramMaker, please judge. I want to find incorrectly ended paragraphs (missing punctuation). For example the following 4 lines are paragraphs, the first 2 correct, the next two incorrect: This is the first paragraph! And this is the second one. And here a third And a fourth one: RegEx Find/Replace with these settings: Find: ([^\.!?])\n Repl: $1.\n Result: find is correct, replacement is n instead of paragraph end With repl = $1.\rreplacement is a forced newline; correct, but not wanted. Find: ([^\.!?])(\n) Repl: $1.$2 This creates a correct replacement! IMHO the behaviour of not honoring \n as an 'end of paragraph' for the replacement is a bug. Do You agree? Klaus Daube ~~ Docu + Design Daube; Schäracher 11; CH-8053 Zürich Technical documentation consultancy; On-line and paper F: +41-44-422 86 25 E: d...@daube.ch W: www.daube.ch ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
RE: Removing custom row heights
Row format. Because this isn't in a Designer window, remove overrides doesn't touch it. Pat From: Shmuel Wolfson [mailto:shmue...@gmail.com] Sent: Sunday, July 06, 2014 9:55 AM To: Christenson, Pat; framers@lists.frameusers.com Subject: Re: Removing custom row heights What do you mean by custom row heights? Do you mean the top and bottom cell margins in the Table Designer are not the same as defined in the table tag, or do you mean the top and bottom cell margins in the Paragraph Designer have custom settings and are not the same throughout the table? Is there another way to set the row heights in a table? Shmuel Wolfson Technical Writer 052-763-7133 On 19-Jun-14 10:36 PM, Christenson, Pat wrote: Almost all our tables have custom row heights - ugh! Does anyone know of a way to global reset the row heights to the defaults? I can't find anything in FrameMaker so I'm wondering if there's an add-on for it. FrameMaker 10, Windows 7 Professional Thanks! Pat Christenson Resource Coordinator Fitzgerald Marketing and Communications pchristen...@ftportfolios.commailto:pchristen...@ftportfolios.com ___ You are currently subscribed to framers as shmue...@gmail.commailto:shmue...@gmail.com. Send list messages to framers@lists.frameusers.commailto:framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.commailto:framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/shmuelw1%40gmail.com Send administrative questions to listad...@frameusers.commailto:listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info. ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
RE: Removing custom row heights
Thanks. I agree – scripting is the only way to go. Pat From: framers-boun...@lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] On Behalf Of Heiko Haida Sent: Sunday, July 06, 2014 1:09 PM To: framers@lists.frameusers.com Subject: Re: Removing custom row heights Hi, the table row format options can only applied individually and are not accessed via a format list (afaik). You could write a script (Framescript or ExtendScript) to change all rows to specific values. (In ExtendScript, the objects are called RowMaxHeight and RowMinHeight.) Best regards - Tino H. Haida Mike Wickham: I don't know if this is what the original poster meant, but Table Format Row Format lets you set minimum and maximum row heights for tables. Mike Wickham On 7/6/2014 9:55 AM, Shmuel Wolfson wrote: What do you mean by custom row heights? ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
RE: FM12: Quirks in Find/replace using RegEx (Perl)
No, I don't think it is a bug. And end-of-paragraph mark is not a simple glyph; it has properties and attributes associated with it (e.g. a paragraph tag, the formatting associated with that paragraph tag, and any overrides to the standard formatting for the tag). You can find an EOP as if it were a simple glyph because they do have a common fundamental property (i.e. denoting the end of a paragraph). But you cannot effectively insert a new EOP in a replace string because there is no way to associate any of the other properties with the new mark. Finding an EOP and replacing it with itself, on the other hand, is a valid operation because the found mark has a full complement of paragraph properties. -Fred Ridder From: fr...@daube.ch To: framers@lists.frameusers.com Date: Mon, 7 Jul 2014 15:48:17 +0200 Subject: FM12: Quirks in Find/replace using RegEx (Perl) Friends of FramMaker, please judge. I want to find incorrectly ended paragraphs (missing punctuation). For example the following 4 lines are paragraphs, the first 2 correct, the next two incorrect: This is the first paragraph! And this is the second one. And here a third And a fourth one: RegEx Find/Replace with these settings: Find: ([^\.!?])\n Repl: $1.\n Result: find is correct, replacement is n instead of paragraph end With repl = $1.\rreplacement is a forced newline; correct, but not wanted. Find: ([^\.!?])(\n) Repl: $1.$2 This creates a correct replacement! IMHO the behaviour of not honoring \n as an 'end of paragraph' for the replacement is a bug. Do You agree? Klaus Daube ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
RE: FM12: Quirks in Find/replace using RegEx (Perl)
Hi, Fred. Hmmm ... I understand your point, but am not sure I would entirely agree with the reasoning. Yes, FrameMaker (and other programs like Word) do put in additional information besides the EOP glyph itself. But, this is a relatively commonly used/desired function - certainly in simple text editors - to replace an EOP with other characters (perhaps including an EOP). For example, to join multiple lines together, or to do what Klaus mentions. Yes, FM is not just a simple text editor, which is why I see your reasoning to not call it a bug. But I think it would be good to define exactly what regular expression matching is supposed to do with EOP markers then (or have a special mechanism to identify and use an EOP more effectively perhaps?) Z From: framers-boun...@lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] On Behalf Of Fred Ridder Sent: Monday, July 07, 2014 8:02 AM To: fr...@daube.ch; framers@lists.frameusers.com Subject: RE: FM12: Quirks in Find/replace using RegEx (Perl) No, I don't think it is a bug. And end-of-paragraph mark is not a simple glyph; it has properties and attributes associated with it (e.g. a paragraph tag, the formatting associated with that paragraph tag, and any overrides to the standard formatting for the tag). You can find an EOP as if it were a simple glyph because they do have a common fundamental property (i.e. denoting the end of a paragraph). But you cannot effectively insert a new EOP in a replace string because there is no way to associate any of the other properties with the new mark. Finding an EOP and replacing it with itself, on the other hand, is a valid operation because the found mark has a full complement of paragraph properties. -Fred Ridder From: fr...@daube.chmailto:fr...@daube.ch To: framers@lists.frameusers.commailto:framers@lists.frameusers.com Date: Mon, 7 Jul 2014 15:48:17 +0200 Subject: FM12: Quirks in Find/replace using RegEx (Perl) Friends of FramMaker, please judge. I want to find incorrectly ended paragraphs (missing punctuation). For example the following 4 lines are paragraphs, the first 2 correct, the next two incorrect: This is the first paragraph! And this is the second one. And here a third And a fourth one: RegEx Find/Replace with these settings: Find: ([^\.!?])\n Repl: $1.\n Result: find is correct, replacement is n instead of paragraph end With repl = $1.\r replacement is a forced newline; correct, but not wanted. Find: ([^\.!?])(\n) Repl: $1.$2 This creates a correct replacement! IMHO the behaviour of not honoring \n as an 'end of paragraph' for the replacement is a bug. Do You agree? Klaus Daube ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
Re: FM12: Quirks in Find/replace using RegEx (Perl)
Hi Klaus... Definitely a bug in that the handling of \n is inconsistent. But I'd wonder what \n is really matching on, and what type of end of line is it? Will this match on a forced return (SHIFT+ENTER) as well as an end of paragraph? And what about the end of flow? I'd feel better if \n didn't match on anything since I don't know that this really applies in a FM document. What about trying $ to indicate an end of line? Definitely a bug though. ...scott On 7/7/14 6:48 AM, Klaus Daube wrote: Friends of FramMaker, please judge. I want to find incorrectly ended paragraphs (missing punctuation). For example the following 4 lines are paragraphs, the first 2 correct, the next two incorrect: This is the first paragraph! And this is the second one. And here a third And a fourth one: RegEx Find/Replace with these settings: Find: ([^\.!?])\n Repl: $1.\n Result: find is correct, replacement is n instead of paragraph end With repl = $1.\rreplacement is a forced newline; correct, but not wanted. Find: ([^\.!?])(\n) Repl: $1.$2 This creates a correct replacement! IMHO the behaviour of not honoring \n as an 'end of paragraph' for the replacement is a bug. Do You agree? Klaus Daube ~~ Docu + Design Daube; Schäracher 11; CH-8053 Zürich Technical documentation consultancy; On-line and paper F: +41-44-422 86 25 E: d...@daube.ch W: www.daube.ch ___ ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
RE: Removing custom row heights
I set the row heights to zero, which I believe is the default. FrameMaker seems to take things over from there using the current paragraph tag to set the height to the minimum without obscuring text. If all your custom settings are the same (for example: 1.56789) you can do a simple search and replace in the mif. Replace: RowMinHeight 1.56789 with RowMinHeight 0 It looks to me like you could reset all tables by just removing the RowMinHeight x.x line from the mif. That would require a more sophisticated find value that used wildcards (or regexp) Try this on a copy of a file and see if that works for you. Craig From: framers-boun...@lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] On Behalf Of Christenson, Pat Sent: Thursday, June 19, 2014 2:36 PM To: framers@lists.frameusers.com Subject: Removing custom row heights Almost all our tables have custom row heights - ugh! Does anyone know of a way to global reset the row heights to the defaults? I can't find anything in FrameMaker so I'm wondering if there's an add-on for it. FrameMaker 10, Windows 7 Professional Thanks! Pat Christenson Resource Coordinator Fitzgerald Marketing and Communications pchristen...@ftportfolios.com ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
Re: Removing custom row heights
Yes, but this could take a long time if you have a lot of tables with a lot of rows. However, if you do the search and replace using a text editor that supports regular expressions (Notepad++, etc.) this could be a good solution. The regular _expression_ to search for would be "RowMinHeight [0-9]*.[0-9]*" (without the quotes) and replace with RowMinHeight 0. Shmuel Wolfson Technical Writer 052-763-7133 On 07-Jul-14 7:12 PM, Craig Ede wrote: I set the row heights to zero, which I believe is the default. FrameMaker seems to take things over from there using the current paragraph tag to set the height to the minimum without obscuring text. If all your custom settings are the same (for example: "1.56789") you can do a simple search and replace in the mif. Replace: RowMinHeight 1.56789" with RowMinHeight 0" It looks to me like you could reset all tables by just removing the RowMinHeight x.x line from the mif. That would require a more sophisticated find value that used wildcards (or regexp) Try this on a copy of a file and see if that works for you. Craig From: framers-boun...@lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] On Behalf Of Christenson, Pat Sent: Thursday, June 19, 2014 2:36 PM To: framers@lists.frameusers.com Subject: Removing custom row heights Almost all our tables have custom row heights ugh! Does anyone know of a way to global reset the row heights to the defaults? I cant find anything in FrameMaker so Im wondering if theres an add-on for it. FrameMaker 10, Windows 7 Professional Thanks! Pat Christenson Resource Coordinator Fitzgerald Marketing and Communications pchristen...@ftportfolios.com ___ You are currently subscribed to framers as shmue...@gmail.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/shmuelw1%40gmail.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info. ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
RE: FM12: Quirks in Find/replace using RegEx (Perl)
Don't get me wrong. I'm not saying that it wouldn't be *useful* to be able to insert a new EOP. But the reality is that in either Word or FrameMaker (and I assume in other word processing applications) it is problematic because EOP is not a simple character. Regular expressions are designed to work with arbitrary strings of simple characters. They were never intended to handle characters that have formatting or page layout properties embedded in them. If a regular expression *were* able to insert a new EOP, what formatting should apply to it? Since regular expressions don't know about formatting, the only practical answer is the lowest level default formatting. But in any properly designed word processor document (i.e., one that uses styles) that default is going to be *wrong* in 99% of cases and require further, manual attention from the author, which really defeats the benefit of being able to use a regular expression replacement. A simple text editor is a completely different situation because there really is nothing special about an EOP. I think the real point is that in Klaus' case the analysis of the task was slightly flawed. To fix his punctuation issue, what he really wants to do is insert a period (full stop) between the current unpunctuated text and the existing EOP, which is exactly what his second regular expression does. There really is no reason to delete the existing EOP (and all the magic embedded in it) and replace it with a brand-new, untagged EOP that would require his manual attention to tag and/or format. FrameMaker's behavior of not allowing this saves the user from having to do a lot of after-the-fact cleanup. FrameMaker's regular expressions let you find EOPs without issue, and lets you reuse them. What they don't let you do is try to create a new one where there is insufficient information in the found text string(s) to do that operation without making a mess. -Fred From: syed.hos...@aeris.net To: docu...@hotmail.com; fr...@daube.ch; framers@lists.frameusers.com Date: Mon, 7 Jul 2014 09:10:33 -0700 Subject: RE: FM12: Quirks in Find/replace using RegEx (Perl) Hi, Fred. Hmmm … I understand your point, but am not sure I would entirely agree with the reasoning. Yes, FrameMaker (and other programs like Word) do put in additional information besides the EOP glyph itself. But, this is a relatively commonly used/desired function – certainly in simple text editors – to replace an EOP with other characters (perhaps including an EOP). For example, to “join” multiple lines together, or to do what Klaus mentions. Yes, FM is not just a simple text editor, which is why I see your reasoning to not call it a bug. But I think it would be good to define exactly what regular expression matching is supposed to do with EOP markers then (or have a special mechanism to identify and use an EOP more effectively perhaps?) Z From: framers-boun...@lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] On Behalf Of Fred Ridder Sent: Monday, July 07, 2014 8:02 AM To: fr...@daube.ch; framers@lists.frameusers.com Subject: RE: FM12: Quirks in Find/replace using RegEx (Perl) No, I don't think it is a bug. And end-of-paragraph mark is not a simple glyph; it has properties and attributes associated with it (e.g. a paragraph tag, the formatting associated with that paragraph tag, and any overrides to the standard formatting for the tag). You can find an EOP as if it were a simple glyph because they do have a common fundamental property (i.e. denoting the end of a paragraph). But you cannot effectively insert a new EOP in a replace string because there is no way to associate any of the other properties with the new mark. Finding an EOP and replacing it with itself, on the other hand, is a valid operation because the found mark has a full complement of paragraph properties. -Fred Ridder From: fr...@daube.ch To: framers@lists.frameusers.com Date: Mon, 7 Jul 2014 15:48:17 +0200 Subject: FM12: Quirks in Find/replace using RegEx (Perl) Friends of FramMaker, please judge. I want to find incorrectly ended paragraphs (missing punctuation). For example the following 4 lines are paragraphs, the first 2 correct, the next two incorrect: This is the first paragraph! And this is the second one. And here a third And a fourth one: RegEx Find/Replace with these settings: Find: ([^\.!?])\n Repl: $1.\n Result: find is correct, replacement is n instead of paragraph end With repl = $1.\r replacement is a forced newline; correct, but not wanted. Find: ([^\.!?])(\n) Repl: $1.$2 This creates a correct replacement! IMHO the behaviour of not honoring \n as an 'end of paragraph' for the replacement is a bug. Do You agree? Klaus Daube ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To
RE: Removing custom row heights
Hi Craig, this kind of manipulation via MIF sounds like a very good idea. I did not check, but I am pretty sure this would work. Best regards - Tino H. Haida Craig Ede: I wasn't suggesting a table by table approach, but a search and replace approach of the kind Shmuel describes. Framemaker could do the search and replace, but Notepad++ is a lot more efficient. Notepad++ seems to work using search and replace as follows (for all tables). You could restrict it to the particular table setting you want removed if you'd like. Use the regular expression option. Set Find to RowMinHeight *.* Set Replace to RowMinHeight 0 If you cut paste a RowMinHeight x.xxx line from the mif, you'll get the right space and tick marks. Here's a JPG showing the options selected in Notepad++. Do a Find Next to make sure you are getting what you want and then do a replace all. Retain a copy of your original file. Note that you can do the replace on a whole series of open documents. Craig FROM: Shmuel Wolfson [mailto:shmue...@gmail.com] SENT: Monday, July 07, 2014 11:42 AM TO: Craig Ede; Framers SUBJECT: Re: Removing custom row heights Yes, but this could take a long time if you have a lot of tables with a lot of rows. However, if you do the search and replace using a text editor that supports regular expressions (Notepad++, etc.) this could be a good solution. The regular expression to search for would be RowMinHeight [0-9]*.[0-9]* (without the quotes) and replace with RowMinHeight 0. Shmuel Wolfson Technical Writer 052-763-7133 On 07-Jul-14 7:12 PM, Craig Ede wrote: I set the row heights to zero, which I believe is the default. FrameMaker seems to take things over from there using the current paragraph tag to set the height to the minimum without obscuring text. If all your custom settings are the same (for example: 1.56789) you can do a simple search and replace in the mif. Replace: RowMinHeight 1.56789 with RowMinHeight 0 It looks to me like you could reset all tables by just removing the RowMinHeight x.x line from the mif. That would require a more sophisticated find value that used wildcards (or regexp) Try this on a copy of a file and see if that works for you. Craig FROM: framers-boun...@lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] ON BEHALF OF Christenson, Pat SENT: Thursday, June 19, 2014 2:36 PM TO: framers@lists.frameusers.com SUBJECT: Removing custom row heights Almost all our tables have custom row heights - ugh! Does anyone know of a way to global reset the row heights to the defaults? I can't find anything in FrameMaker so I'm wondering if there's an add-on for it. FrameMaker 10, Windows 7 Professional Thanks! Pat Christenson Resource Coordinator Fitzgerald Marketing and Communications pchristen...@ftportfolios.com ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
Re: FM12: Quirks in Find/replace using RegEx (Perl)
On 7 Jul 2014 at 11:02, Fred Ridder wrote: No, I don't think it is a bug. And end-of-paragraph mark is not a simple glyph; it has properties and attributes associated with it (e.g. a paragraph tag, the formatting associated with that paragraph tag, and any overrides to the standard formatting for the tag). ... Thank You Fred for Your reasoning! After that I agree with you that the second method of my replacement is the only correct one - and according to the design of RegExes. I was thinking in the plain text editor mode ... Klaus Daube ~~ Docu + Design Daube; Schäracher 11; CH-8053 Zürich Technical documentation consultancy; On-line and paper F: +41-44-422 86 25 E: d...@daube.ch W: www.daube.ch ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
RE: FM12: Quirks in Find/replace using RegEx (Perl)
Yeah ... I have to admit that I can't argue with you on this too much. :) Because, there isn't a simple this is the right way to do the EOP insertions. Although ... maybe ... Word stands a slightly better chance because of its Normal paragraph that could get applied by default. Of course, as you note, this could cause a mess with documents whose paragraphs have already been changed to some other paragraph format, etc. Z From: Fred Ridder [mailto:docu...@hotmail.com] Sent: Monday, July 07, 2014 10:18 AM To: Syed Zaeem Hosain (syed.hos...@aeris.net); fr...@daube.ch; framers@lists.frameusers.com Subject: RE: FM12: Quirks in Find/replace using RegEx (Perl) Don't get me wrong. I'm not saying that it wouldn't be *useful* to be able to insert a new EOP. But the reality is that in either Word or FrameMaker (and I assume in other word processing applications) it is problematic because EOP is not a simple character. Regular expressions are designed to work with arbitrary strings of simple characters. They were never intended to handle characters that have formatting or page layout properties embedded in them. If a regular expression *were* able to insert a new EOP, what formatting should apply to it? Since regular expressions don't know about formatting, the only practical answer is the lowest level default formatting. But in any properly designed word processor document (i.e., one that uses styles) that default is going to be *wrong* in 99% of cases and require further, manual attention from the author, which really defeats the benefit of being able to use a regular expression replacement. A simple text editor is a completely different situation because there really is nothing special about an EOP. I think the real point is that in Klaus' case the analysis of the task was slightly flawed. To fix his punctuation issue, what he really wants to do is insert a period (full stop) between the current unpunctuated text and the existing EOP, which is exactly what his second regular expression does. There really is no reason to delete the existing EOP (and all the magic embedded in it) and replace it with a brand-new, untagged EOP that would require his manual attention to tag and/or format. FrameMaker's behavior of not allowing this saves the user from having to do a lot of after-the-fact cleanup. FrameMaker's regular expressions let you find EOPs without issue, and lets you reuse them. What they don't let you do is try to create a new one where there is insufficient information in the found text string(s) to do that operation without making a mess. -Fred From: syed.hos...@aeris.netmailto:syed.hos...@aeris.net To: docu...@hotmail.commailto:docu...@hotmail.com; fr...@daube.chmailto:fr...@daube.ch; framers@lists.frameusers.commailto:framers@lists.frameusers.com Date: Mon, 7 Jul 2014 09:10:33 -0700 Subject: RE: FM12: Quirks in Find/replace using RegEx (Perl) Hi, Fred. Hmmm ... I understand your point, but am not sure I would entirely agree with the reasoning. Yes, FrameMaker (and other programs like Word) do put in additional information besides the EOP glyph itself. But, this is a relatively commonly used/desired function - certainly in simple text editors - to replace an EOP with other characters (perhaps including an EOP). For example, to join multiple lines together, or to do what Klaus mentions. Yes, FM is not just a simple text editor, which is why I see your reasoning to not call it a bug. But I think it would be good to define exactly what regular expression matching is supposed to do with EOP markers then (or have a special mechanism to identify and use an EOP more effectively perhaps?) Z From: framers-boun...@lists.frameusers.commailto:framers-boun...@lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] On Behalf Of Fred Ridder Sent: Monday, July 07, 2014 8:02 AM To: fr...@daube.chmailto:fr...@daube.ch; framers@lists.frameusers.commailto:framers@lists.frameusers.com Subject: RE: FM12: Quirks in Find/replace using RegEx (Perl) No, I don't think it is a bug. And end-of-paragraph mark is not a simple glyph; it has properties and attributes associated with it (e.g. a paragraph tag, the formatting associated with that paragraph tag, and any overrides to the standard formatting for the tag). You can find an EOP as if it were a simple glyph because they do have a common fundamental property (i.e. denoting the end of a paragraph). But you cannot effectively insert a new EOP in a replace string because there is no way to associate any of the other properties with the new mark. Finding an EOP and replacing it with itself, on the other hand, is a valid operation because the found mark has a full complement of paragraph properties. -Fred Ridder From: fr...@daube.chmailto:fr...@daube.ch To: framers@lists.frameusers.commailto:framers@lists.frameusers.com Date: Mon, 7 Jul 2014 15:48:17 +0200 Subject: FM12: Quirks in
Re: FM12: Quirks in Find/replace using RegEx (Perl)
I dunno. I just don't like the fact that \n will match on a line end (of some type), while it replaces as an n .. that's not right. ...scott On 7/7/14 4:52 PM, Syed Zaeem Hosain (syed.hos...@aeris.net) wrote: Yeah ... I have to admit that I can't argue with you on this too much. JBecause, there isn't a simple this is the right way to do the EOP insertions. Although ... /maybe/ ... Word stands a slightly better chance because of its Normal paragraph that /could/ get applied by default. Of course, as you note, this could cause a mess with documents whose paragraphs have already been changed to some other paragraph format, etc. Z *From:*Fred Ridder [mailto:docu...@hotmail.com] *Sent:* Monday, July 07, 2014 10:18 AM *To:* Syed Zaeem Hosain (syed.hos...@aeris.net); fr...@daube.ch; framers@lists.frameusers.com *Subject:* RE: FM12: Quirks in Find/replace using RegEx (Perl) Don't get me wrong. I'm not saying that it wouldn't be *useful* to be able to insert a new EOP. But the reality is that in either Word or FrameMaker (and I assume in other word processing applications) it is problematic because EOP is not a simple character. Regular expressions are designed to work with arbitrary strings of simple characters. They were never intended to handle characters that have formatting or page layout properties embedded in them. If a regular expression *were* able to insert a new EOP, what formatting should apply to it? Since regular expressions don't know about formatting, the only practical answer is the lowest level default formatting. But in any properly designed word processor document (i.e., one that uses styles) that default is going to be *wrong* in 99% of cases and require further, manual attention from the author, which really defeats the benefit of being able to use a regular expression replacement. A simple text editor is a completely different situation because there really is nothing special about an EOP. I think the real point is that in Klaus' case the analysis of the task was slightly flawed. To fix his punctuation issue, what he really wants to do is insert a period (full stop) between the current unpunctuated text and the existing EOP, which is exactly what his second regular expression does. There really is no reason to delete the existing EOP (and all the magic embedded in it) and replace it with a brand-new, untagged EOP that would require his manual attention to tag and/or format. FrameMaker's behavior of not allowing this saves the user from having to do a lot of after-the-fact cleanup. FrameMaker's regular expressions let you find EOPs without issue, and lets you reuse them. What they don't let you do is try to create a new one where there is insufficient information in the found text string(s) to do that operation without making a mess. -Fred From: syed.hos...@aeris.net mailto:syed.hos...@aeris.net To: docu...@hotmail.com mailto:docu...@hotmail.com; fr...@daube.ch mailto:fr...@daube.ch; framers@lists.frameusers.com mailto:framers@lists.frameusers.com Date: Mon, 7 Jul 2014 09:10:33 -0700 Subject: RE: FM12: Quirks in Find/replace using RegEx (Perl) Hi, Fred. Hmmm ... I understand your point, but am not sure I would /entirely/ agree with the reasoning. Yes, FrameMaker (and other programs like Word) do put in additional information besides the EOP glyph itself. But, this is a relatively commonly used/desired function -- certainly in simple text editors -- to replace an EOP with other characters (perhaps including an EOP). For example, to join multiple lines together, or to do what Klaus mentions. Yes, FM is /not/ just a simple text editor, which is why I see your reasoning to not call it a bug. But I think it would be good to define exactly what regular expression matching is supposed to do with EOP markers then (or have a special mechanism to identify /and/ use an EOP more effectively perhaps?) Z *From:*framers-boun...@lists.frameusers.com mailto:framers-boun...@lists.frameusers.com [mailto:framers-boun...@lists.frameusers.com] *On Behalf Of *Fred Ridder *Sent:* Monday, July 07, 2014 8:02 AM *To:* fr...@daube.ch mailto:fr...@daube.ch; framers@lists.frameusers.com mailto:framers@lists.frameusers.com *Subject:* RE: FM12: Quirks in Find/replace using RegEx (Perl) No, I don't think it is a bug. And end-of-paragraph mark is not a simple glyph; it has properties and attributes associated with it (e.g. a paragraph tag, the formatting associated with that paragraph tag, and any overrides to the standard formatting for the tag). You can find an EOP as if it were a simple glyph because they do have a common fundamental property (i.e. denoting the end of a paragraph). But you cannot effectively insert a new EOP in a replace string because there is no way to associate any of the other properties with the new mark. Finding an EOP and replacing it with
RE: FM12: Quirks in Find/replace using RegEx (Perl)
But if there is no practical way for a plain text-oriented tool to insert a *proper* EOP, the only way to make Frame's overall Find/Replace behavior consistent would be to forbid searching for EOPs. And that would be a *real* shortcoming IMO. Kind of like throwing out the baby with the bathwater... -Fred Date: Mon, 7 Jul 2014 16:57:03 -0700 From: s...@leximation.com To: framers@lists.frameusers.com Subject: Re: FM12: Quirks in Find/replace using RegEx (Perl) I dunno. I just don't like the fact that \n will match on a line end (of some type), while it replaces as an n .. that's not right. ...scott On 7/7/14 4:52 PM, Syed Zaeem Hosain (syed.hos...@aeris.net) wrote: Yeah … I have to admit that I can’t argue with you on this too much. J Because, there isn’t a simple “this is the right way” to do the EOP insertions. Although … maybe … Word stands a slightly better chance because of its “Normal” paragraph that could get applied by default. Of course, as you note, this could cause a mess with documents whose paragraphs have already been changed to some other paragraph format, etc. Z From: Fred Ridder [mailto:docu...@hotmail.com] Sent: Monday, July 07, 2014 10:18 AM To: Syed Zaeem Hosain (syed.hos...@aeris.net); fr...@daube.ch; framers@lists.frameusers.com Subject: RE: FM12: Quirks in Find/replace using RegEx (Perl) Don't get me wrong. I'm not saying that it wouldn't be *useful* to be able to insert a new EOP. But the reality is that in either Word or FrameMaker (and I assume in other word processing applications) it is problematic because EOP is not a simple character. Regular expressions are designed to work with arbitrary strings of simple characters. They were never intended to handle characters that have formatting or page layout properties embedded in them. If a regular expression *were* able to insert a new EOP, what formatting should apply to it? Since regular expressions don't know about formatting, the only practical answer is the lowest level default formatting. But in any properly designed word processor document (i.e., one that uses styles) that default is going to be *wrong* in 99% of cases and require further, manual attention from the author, which really defeats the benefit of being able to use a regular expression replacement. A simple text editor is a completely different situation because there really is nothing special about an EOP. I think the real point is that in Klaus' case the analysis of the task was slightly flawed. To fix his punctuation issue, what he really wants to do is insert a period (full stop) between the current unpunctuated text and the existing EOP, which is exactly what his second regular expression does. There really is no reason to delete the existing EOP (and all the magic embedded in it) and replace it with a brand-new, untagged EOP that would require his manual attention to tag and/or format. FrameMaker's behavior of not allowing this saves the user from having to do a lot of after-the-fact cleanup. FrameMaker's regular expressions let you find EOPs without issue, and lets you reuse them. What they don't let you do is try to create a new one where there is insufficient information in the found text string(s) to do that operation without making a mess. -Fred ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
Re: FM12: Quirks in Find/replace using RegEx (Perl)
There's no reason the plain-text replacement can't add EOPs .. just need a code to do that. You can do that with a regular search/replace by searching on \p and replacing with \p\p. The \n is a forced return in the non-regex UI. It should at least do the same .. not an n. ...scott On 7/7/14 6:07 PM, Fred Ridder wrote: But if there is no practical way for a plain text-oriented tool to insert a *proper* EOP, the only way to make Frame's overall Find/Replace behavior consistent would be to forbid searching for EOPs. And that would be a *real* shortcoming IMO. Kind of like throwing out the baby with the bathwater... -Fred Date: Mon, 7 Jul 2014 16:57:03 -0700 From: s...@leximation.com To: framers@lists.frameusers.com Subject: Re: FM12: Quirks in Find/replace using RegEx (Perl) I dunno. I just don't like the fact that \n will match on a line end (of some type), while it replaces as an n .. that's not right. ...scott On 7/7/14 4:52 PM, Syed Zaeem Hosain (syed.hos...@aeris.net mailto:syed.hos...@aeris.net) wrote: Yeah … I have to admit that I can’t argue with you on this too much. JBecause, there isn’t a simple “this is the right way” to do the EOP insertions. Although … /maybe/ … Word stands a slightly better chance because of its “Normal” paragraph that /could/ get applied by default. Of course, as you note, this could cause a mess with documents whose paragraphs have already been changed to some other paragraph format, etc. Z *From:*Fred Ridder [mailto:docu...@hotmail.com] *Sent:* Monday, July 07, 2014 10:18 AM *To:* Syed Zaeem Hosain (syed.hos...@aeris.net mailto:syed.hos...@aeris.net); fr...@daube.ch mailto:fr...@daube.ch; framers@lists.frameusers.com mailto:framers@lists.frameusers.com *Subject:* RE: FM12: Quirks in Find/replace using RegEx (Perl) Don't get me wrong. I'm not saying that it wouldn't be *useful* to be able to insert a new EOP. But the reality is that in either Word or FrameMaker (and I assume in other word processing applications) it is problematic because EOP is not a simple character. Regular expressions are designed to work with arbitrary strings of simple characters. They were never intended to handle characters that have formatting or page layout properties embedded in them. If a regular expression *were* able to insert a new EOP, what formatting should apply to it? Since regular expressions don't know about formatting, the only practical answer is the lowest level default formatting. But in any properly designed word processor document (i.e., one that uses styles) that default is going to be *wrong* in 99% of cases and require further, manual attention from the author, which really defeats the benefit of being able to use a regular expression replacement. A simple text editor is a completely different situation because there really is nothing special about an EOP. I think the real point is that in Klaus' case the analysis of the task was slightly flawed. To fix his punctuation issue, what he really wants to do is insert a period (full stop) between the current unpunctuated text and the existing EOP, which is exactly what his second regular expression does. There really is no reason to delete the existing EOP (and all the magic embedded in it) and replace it with a brand-new, untagged EOP that would require his manual attention to tag and/or format. FrameMaker's behavior of not allowing this saves the user from having to do a lot of after-the-fact cleanup. FrameMaker's regular expressions let you find EOPs without issue, and lets you reuse them. What they don't let you do is try to create a new one where there is insufficient information in the found text string(s) to do that operation without making a mess. -Fred ___ You are currently subscribed to framers as arch...@mail-archive.com. Send list messages to framers@lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscr...@lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to listad...@frameusers.com. Visit http://www.frameusers.com/ for more resources and info.
Removing custom row heights
I wasn't suggesting a table by table approach, but a search and replace approach of the kind Shmuel describes. Framemaker could do the search and replace, but Notepad++ is a lot more efficient. Notepad++ seems to work using search and replace as follows (for all tables). You could restrict it to the particular table setting you want removed if you'd like. Use the regular expression option. Set Find to Set Replace to If you cut & paste a line from the mif, you'll get the right space and tick marks. Here's a JPG showing the options selected in Notepad++. Do a Find Next to make sure you are getting what you want and then do a replace all. Retain a copy of your original file. Note that you can do the replace on a whole series of open documents. search.JPG Craig From: Shmuel Wolfson [mailto:shmue...@gmail.com] Sent: Monday, July 07, 2014 11:42 AM To: Craig Ede; Framers Subject: Re: Removing custom row heights Yes, but this could take a long time if you have a lot of tables with a lot of rows. However, if you do the search and replace using a text editor that supports regular expressions (Notepad++, etc.) this could be a good solution. The regular expression to search for would be "RowMinHeight [0-9]*.[0-9]*" (without the quotes) and replace with RowMinHeight 0. Shmuel Wolfson Technical Writer 052-763-7133 On 07-Jul-14 7:12 PM, Craig Ede wrote: I set the row heights to zero, which I believe is the default. FrameMaker seems to take things over from there using the current paragraph tag to set the height to the minimum without obscuring text. If all your custom settings are the same (for example: "1.56789") you can do a simple search and replace in the mif. Replace: with It looks to me like you could reset all tables by just removing the line from the mif. That would require a more sophisticated find value that used wildcards (or regexp) Try this on a copy of a file and see if that works for you. Craig From: framers-boun...@lists.frameusers.com [mailto:framers-bounces at lists.frameusers.com] On Behalf Of Christenson, Pat Sent: Thursday, June 19, 2014 2:36 PM To: framers at lists.frameusers.com Subject: Removing custom row heights Almost all our tables have custom row heights - ugh! Does anyone know of a way to global reset the row heights to the defaults? I can't find anything in FrameMaker so I'm wondering if there's an add-on for it. FrameMaker 10, Windows 7 Professional Thanks! Pat Christenson Resource Coordinator Fitzgerald Marketing and Communications PChristenson at ftportfolios.com ___ You are currently subscribed to framers as shmuelw1 at gmail.com. Send list messages to framers at lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscribe at lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/shmuelw1%40gmail.com Send administrative questions to listadmin at frameusers.com. Visit http://www.frameusers.com/ for more resources and info. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.frameusers.com/pipermail/framers/attachments/20140707/3effdda4/attachment.html> -- next part -- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 35498 bytes Desc: not available URL: <http://lists.frameusers.com/pipermail/framers/attachments/20140707/3effdda4/attachment.jpe> -- next part -- A non-text attachment was scrubbed... Name: search.JPG Type: image/jpeg Size: 35498 bytes Desc: not available URL: <http://lists.frameusers.com/pipermail/framers/attachments/20140707/3effdda4/attachment-0001.jpe>
Removing custom row heights
Hi all - I really appreciate all the suggestions but doing a Find/Change through MIF is one of the first things I thought of and then rejected, mainly because it wouldn't really save time or effort. We have hundreds of books, each containing 5-15 files. When you consider saving the files in MIF, running the Find/Change, saving the files again, reopening them in Frame and saving them as Frame docs ... well, it's still a lot of manual effort. Creating an ExtendScript is probably not a big deal for someone who knows Java/ExtendScript we can't spend money to get that done. I have a couple ideas and I'll let you know how they work out. Thanks again! Pat From: Craig Ede [mailto:craig...@hotmail.com] Sent: Monday, July 07, 2014 12:11 PM To: Christenson, Pat; framers at lists.frameusers.com Subject: RE: Removing custom row heights I wasn't suggesting a table by table approach, but a search and replace approach of the kind Shmuel describes. Framemaker could do the search and replace, but Notepad++ is a lot more efficient. Notepad++ seems to work using search and replace as follows (for all tables). You could restrict it to the particular table setting you want removed if you'd like. Use the regular expression option. Set Find to Set Replace to If you cut & paste a line from the mif, you'll get the right space and tick marks. Here's a JPG showing the options selected in Notepad++. Do a Find Next to make sure you are getting what you want and then do a replace all. Retain a copy of your original file. Note that you can do the replace on a whole series of open documents. [search.JPG] Craig From: Shmuel Wolfson [mailto:shmue...@gmail.com] Sent: Monday, July 07, 2014 11:42 AM To: Craig Ede; Framers Subject: Re: Removing custom row heights Yes, but this could take a long time if you have a lot of tables with a lot of rows. However, if you do the search and replace using a text editor that supports regular expressions (Notepad++, etc.) this could be a good solution. The regular expression to search for would be "RowMinHeight [0-9]*.[0-9]*" (without the quotes) and replace with RowMinHeight 0. Shmuel Wolfson Technical Writer 052-763-7133 On 07-Jul-14 7:12 PM, Craig Ede wrote: I set the row heights to zero, which I believe is the default. FrameMaker seems to take things over from there using the current paragraph tag to set the height to the minimum without obscuring text. If all your custom settings are the same (for example: "1.56789") you can do a simple search and replace in the mif. Replace: with It looks to me like you could reset all tables by just removing the line from the mif. That would require a more sophisticated find value that used wildcards (or regexp) Try this on a copy of a file and see if that works for you. Craig From: framers-bounces at lists.frameusers.com<mailto:framers-bounces at lists.frameusers.com> [mailto:framers-boun...@lists.frameusers.com] On Behalf Of Christenson, Pat Sent: Thursday, June 19, 2014 2:36 PM To: framers at lists.frameusers.com<mailto:framers at lists.frameusers.com> Subject: Removing custom row heights Almost all our tables have custom row heights - ugh! Does anyone know of a way to global reset the row heights to the defaults? I can't find anything in FrameMaker so I'm wondering if there's an add-on for it. FrameMaker 10, Windows 7 Professional Thanks! Pat Christenson Resource Coordinator Fitzgerald Marketing and Communications PChristenson at ftportfolios.com<mailto:PChristenson at ftportfolios.com> ___ You are currently subscribed to framers as shmuelw1 at gmail.com<mailto:shmuelw1 at gmail.com>. Send list messages to framers at lists.frameusers.com<mailto:framers at lists.frameusers.com>. To unsubscribe send a blank email to framers-unsubscribe at lists.frameusers.com<mailto:framers-unsubscribe at lists.frameusers.com> or visit http://lists.frameusers.com/mailman/options/framers/shmuelw1%40gmail.com Send administrative questions to listadmin at frameusers.com<mailto:listadmin at frameusers.com>. Visit http://www.frameusers.com/ for more resources and info. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.frameusers.com/pipermail/framers/attachments/20140707/6bcd61f3/attachment.html> -- next part -- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 35498 bytes Desc: image001.jpg URL: <http://lists.frameusers.com/pipermail/framers/attachments/20140707/6bcd61f3/attachment.jpg>
