[www.theword.net]

Twitter live feed  
View unanswered posts | View active topics It is currently Tue Aug 22, 2017 4:40 pm



Reply to topic  [ 15 posts ] 
 Tips & Software for creating, formatting, converting modules 
Author Message

Joined: Thu Nov 08, 2012 10:24 pm
Posts: 418
Post Tips & Software for creating, formatting, converting modules
.
Introduction

Welcome to a section in which all experienced module creators can share their discoveries with each other regarding new and better ways of preparing user-modules, including creation, conversion, text manipulation, and formatting. The main article is below, divided into two main sections: (1) Tips on building and formatting the module, and (2) Recommended software that can assist us in this process.

While Dr. Costas already has a nice introductory article on this subject for beginners, addressing the more technical aspect, and while David Cox offers a complete online manual (http://www.thewordtutorial.com/) I would like for us to emphasize here the aspect of formatting (although all suggestions will certainly be welcomed.)

In fact, as you share your ideas, allow me to integrate them into the main article below eventually, grouped according to topic, so that they will be easier for other readers to find. I will be sure to give each contributor credit by name, in the article, together with his observation (as you will see that I have already done in some parts.) In fact, if you find similar tips from other people on other parts of the forum, call it to my attention here, and I will try to include them in this one main article, together with the source and its author, so that all the tips on formatting will be consolidated here.

Feel free to disagree with any of the opinions in the text. I will be happy to reconsider my own, and possibly even incorporate contrary points of view into of the article, so that readers may see both sides of the issue.

Check back, every few weeks, as this list will be continually expanded with new ideas, new links to additional resources, and new links to free software that can be used for module preparation.
.

_________________
.
I'm an Independent Baptist running TheWord portable v 5.0.0.1481 from an external 500GB hard drive with over 1,900 modules installed and loaded in my current module set. I'm using 32-bit Vista Ultimate SP1 with a 2.7gHz processor and 4GB RAM.
.


Last edited by ErikJon on Fri Jul 01, 2016 2:57 am, edited 13 times in total.



Wed Jan 06, 2016 3:53 am
Profile

Joined: Thu Nov 08, 2012 10:24 pm
Posts: 418
Post 
.
Tips for Creating, Formatting, and Converting Modules

by Erik Magnusson. Updated February 7, 2017

Locking modules. A big complaint is when module creators lock their finished module permanently, in such a way that others cannot make helpful improvements to it. Sometimes all that others want to do is correct some spelling mistakes, but they are forbidden to do even that. My suggestion is not to lock any module unless it is absolutely necessary, or requested by the author. (I also suggest that we never ask the author about locking his material, but only that we ask for permission to use it, as we may otherwise complicate the process for ourselves.)

To see one of the disadvantages to locking modules, see the "properties" window "about" tab of Dr. Peter Pett's Commentary module; a mysterious blue background color was inadvertently added when pasting the text, and as the module is now locked, there is nothing that any end-user can do to correct it. (See screenshot below)

However, having said that, there is an advantage to putting some kind of protection on these modules, so that they will not easily be damaged by accident: stray mouse movements, stray keystrokes, selecting and deleting text by accident, are common examples. What is worse, as of version 5.0, once the user clicks outside the module window, whatever changes were made up until that moment are saved forever, and the original text cannot be recovered, not even with the "undo" keystroke.

Nevertheless, an easier solution to prevent accidental modification is available, whereby the module still does not have to be locked permanently. There is a temporary lock that the user himself can apply to the module (which the creator can also apply by default). The quick-and-easy way to apply it is with the CTRL+SHIFT+U keystroke combination whenever the cursor is within the bookview window. The long way is to go to the "Settings/Actions" tab of each module and to de-select "User module (can be edited)". Again, this can be done before distributing the module, and in this way, it will be temporarily locked to prevent accidental changes, but the lock can also be disabled by the user at will. Users who are unaware of how to do this will run not run any risk of accidentally unlocking the module, and those who are aware of it will tend to be more conscious of that possibility anyway.

Chapter divisions. Ideally an ordinary book module should be divided by chapter, so that the title of each chapter is visible in the "topic tree." This should only be done whenever the divisions logically separate main ideas and also reflect the divisions of the original printed work from which the module was derived.

However, if the original work was divided only in order to save paper, to make smaller volumes, or if the text came from a website that divided the text into separate web pages in order to allow for more advertising overall, then it is preferable not to maintain those artificial divisions in your module, but rather to join all those divisions into complete chapters.

For example, let's suppose that you come across a collection online entitled "Choice Gems of Dr. John G. Preacher," a book of only three chapters containing 752 of his most clever sayings on three subjects. The three chapters in the printed work are these: "Sayings About God," "Sayings About Mankind," and "Sayings About the Body of Christ." In fact, you come across the "Table of Contents" that confirms that there were no divisions beyond that in the original work.

As you read through the text, you discover that the entire text has been spread out across twenty separate pages on the website. The first page begins with the heading "Sayings About God," but the next page begins with "Sayings About God, continued" or perhaps it says "Sayings About God, part 2." Well, in that case, you should realize that the text has been divided by the person who prepared the website, but not by the author or editor of the original printed work.

Consequently, you may copy the text verbatim, at first, for the sake of transferring it to you computer and keeping things organized within your word processor, but, after that, you should re-join all the text back into its original three chapters, before publishing your module. As the original work had only three chapters, your finished module should have only three chapters, as well. Retaining those twenty recent artificial divisions has no practical value to the end user, but rather only complicates the use of the new module, requiring more clickng, more scrolling, and more navigation, to read through through twenty different "topics."

Margins. We sometimes forget that these modules are meant to be used, not just placed on a shelf and admired. Neither are we creating brochures or posters that will be placed on a wall to be used independently of the program. There is no reason therefore, in my opinion, to create facsimiles with these modules, but only to reproduce the text faithfully, within reason, for utilitarian purposes.

Consequently, as screen space comes at a premium, for example, I believe that it is not convenient to incorporate pretty "margins" into the module, nor blank spaces at the beginning and end of any module text--even if they were present in the original--as it requires of the user more frequent scrolling. Rather, Costas has already integrated into the program a means of DISPLAYING margins rather than incorporating them into the text. Namely, this function is found at "Options-->Reader's margins". Those users who want wider margins can have them, but the rest of us would like as much text in view as possible, so as never to scroll until necessary. JG recently re-formatted the International Standard Bible Encyclopedia, for example, to remove these excess spaces from the original edition of the mdule, and all duplicate paragraphs, and the result was a wonderful, much more efficient module. Download it here: http://www.theword.net/index.php?downlo ... &l=english)

Spacing between paragraphs. Such spacing is certainly useful and increases the overall legibility of any module. However, I find it better to add such spaces not by "double-spacing" between paragraphs, but rather by applying the "paragraph" context menu item globally to the topic. In other words, after preparing your raw text, I suggest that you first delete all empty carriage returns between paragraphs--but still keep them separated--then paste the text into your new module; then select all the text, and then from "paragraph" in the context menu, add 10pts globally to be applied at the end of every paragraph. This will have the effect of adding the same space that you wanted originally, but without inserting any blank lines (empty carriage returns). In this way, if you ever want even more space, or less, instead of manually selecting 500 empty lines between paragraphs for example, you will simply "select all" the text and then, once again, from the same context menu "paragraph" item, you can re-adjust the spacing globally with just a few clicks.

In fact, the "global" formatting option only affects one topic at a time—not the whole module. We are hoping that Costas will eventually create a means for making such adjustments to the entire corpus of text in any given module at one time.

Spacing at the beginning of paragraphs. As you may know, the context-menu option, "Paragraph," which takes you to a dialog box that allows the adjustment of different aspects of the text, allows space to be added at the beginning of each paragraph, in addition to the end of each. In my many years of typesetting, I have rarely ever needed to add spacing before a paragraph, but usually only AFTER each paragraph (and rarely ever both before and after). In the realm of module preparation, I feel confident that you will never need to add spacing BEFORE any paragraph, but only AFTER, and by the means described in the paragraph above, so stick to adding after paragraphs for the time being, and see if you don’t agree with me in the long run.

Spacing at the beginning and end of each topic. In the context of TheWord, by "topic" I mean to refer to all the text that appears in any one time in the right-hand panel when clicking on an item in the index panel to the left. Now, while it certainly looks nice in print, on paper, to have good margins, or a few extra spaces at the top and bottom of a printed page, in our digital modules it is undesirable, and in fact, counter-productive. The idea is to read text and avoid scrolling, as much as possible, in order to read more. Every blank line of text that you put at the beginning or end of your topic text will require the user to scroll up or down just a bit more than he would otherwise, to view the same amount of text. Consequently, it is recommended that you begin every topic with text in the very first available space, and that you not leave any excess at the end of your topic either.

Leading. This word is the traditional typographer’s term for what others call "spacing between lines of text" or "line spacing" (and in this context it is pronounced "ledding".) On a typewriter we used to call it “single-spacing” and “double-spacing” and so forth, but on a computer we can fine-tune the spacing more precisely. Anyway, while greater leading is said to be easier on the eyes than tight leading, TheWord is already designed to take that fact into account, so that even with single-spaced leading, the text should be easy to read. The additional benefit is that with single-spaced leading you can fit more text into each window, requiring less scrolling of the user. The conclusion is that you always use "single-spaced" leading for your entire corpus of text. (See before/after screenshots below).

Majuscules (Capital letters). Studies show that any text in all capital letters is automatically just a bit harder for people to read, especially when the phrases are longer, and especially when used in the body text. When was the last time you saw a printed book with the entire body text in capital letters? If the answer is “never,” now you know the reason.

Traditionally majuscules have been reserved only for headlines and other special situations, but not for body text. Nevertheless, using “title case” with bold-faced type is probably an even better approach than using all capital letters in your headlines. Moreover, the tradition is to have your headlines just a bit larger than the body text also, usually by two-point increments (e.g., if the body text is at 10pt type, the section headlines might be at 12pt and the main headlines at 14pt or 18pt, depending. Keep that in mind for your tables-of-contents, chapter headings, and title pages.

However, if your original raw text already had lots of capital letters in it, and you are simply trying to format it as quickly and easily as possible to make a module, I suggest that you not worry yourself much; make sure the body text is in ordinary "sentence case" and leave the headlines as they were; otherwise open up a word-processor and use the formatting tools to select your headlines one by one, and apply instantly an automatic re-formatting into bold "title case".

The "about" tab. In the “about” tab of the “module properties” window, I think we should always add a quick Wikipedia biography about the author, whenever possible, together with a portrait of the same. In the case of modern authors yet unknown on Wikipedia, we can often find such brief biographies, educational background information, and photos, on the author's website, or by doing a search online. Below is a screenshot of a suggested format. In fact, lately, after composing a brief biography like that, I have been saving the text together with the portraits, as a separate document on my computer, in order to reuse it whenever I find another module by the same author—including one that someone else created.

It goes without saying that, in the case of authors still alive, if we take the time to include a brief biography and picture, it may also make them feel honored enough to offer additional material and updates, in the future.

In the "about" tab we should also include somewhere the denominational background about the author and any other details that can help us to quickly identify his doctrinal beliefs and affiliations Was he a Freewill Baptist? a PCA Presbyterian? an Episcopalian? a charismatic Calvinist? Feel free to elaborate beyond these simple labels as well, as sometimes the author has a mixed theology. All of such information helps us to understand the setting in which the book was written, and the doctrinal point of view to take into account as we read. In many cases, when we see this doctrinal point of view up front, we will immediately know whether the work will be of use to us or not, in the particular study that we have at hand, as some denominations we consider to be doctrinally sound in one area and weak in others (I will leave that to your own judgment).

Title pages. Some module creators put a scanned image of the cover in place of the title topic text. While this is certainly pretty, I am sure that this adds to the overall file size of the document--as graphics always do. After installing a few hundred modules like that, the program starts to behave a bit more sluggishly when those modules are open and linked to the Bible text.

While some use graphic images for the title, other module creators attempt to re-create the original title page with text, but go to great lengths to make it look exactly as found in the printed book. These look wonderful, if the purpose is to create a facsimile. But I don't think that this should be the purpose in TheWord. I think that, as long as all the entire original text is present and legible, we ought to keep it compact, and easy to use for reading and searching, all without having to do much scrolling. We don't need to worry about the original type sizes and the adornments, as they were often just arbitrary decisions made by the original printer or publisher; they do not help the text, itself in any way, but may even detract from it. Some module creators have stacked the title in 36pt type and the rest, in 12pt, and as a result, one has to scroll down just to read the title! As we will not be holding the book in our hands anymore, nor storing it on a shelf, but using it practically, for research, for reading, for copying, for pasting, and for searching, the more we can format the text for utilitarian rather than aesthetic purposes, the better, but within reason. We can make the module attractive in many ways without sacrificing functionality.

Text colors to use. Personally, I would stick to using only the color black for all text, as the contrast is strongest and most legible that way (assuming that the background is of a light color). This is the general rule in the printing industry also.

An exception to the rule would be the case of footnotes. If the raw text came from an OCR scan of a printed book, and each footnote appeared at the bottom of the pages in the original, it likely ended up in the middle of the text in the digitized result that you are trying to use to make your module (the same may be true with page numbers, headers and footers, etc.) It may not be worth your trouble to go through all 500 pages just to collect all the footnotes and move them to the end of the text, but a work-around solution is what Josh Bond did in his College Press [green book] Commentary module; he used black for the main text, and gray only for footnotes and other secondary information that appeared after every few paragraphs. In other words, he used a color of lesser intensity for remarks of much lesser importance, which produced the effect of reminding the reader that those footnotes were not part of the body and could be theoretically "skipped over" while reading, so that the reader would not to lose the flow and his train of thought. Josh was dealing with thousands of pages of text, so this work-around became all the more important.

In fact, you may even find some texts online that also use this technique of alternating between black type and gray, already formatted nicely. If you copy a text like that as is, and paste it as is into your new module window (rather than trying to convert it first in a word processor), TheWord does a fairly good job of retaining the original formatting.

Text colors NOT to use. HYPERLINK BLUE. While you should use only black for your body text, some people like to use color for the headlines and titles. While colors may make your module more attractive, let us not lay aside the issue of practicality. It is usually not advisable to use standard “medium blue” for any of the text in any module, for example, as this color has already been reserved for Bible-reference links, hyperlinks, and so forth. By using this color for headlines or key words, you will confuse the reader, making him think that those words are linked. By the same token, it is recommend that, in general, you avoid underlining text also--and especially colored text--as, these days, the underline often implies that the underlined text is linked to something else.

RED. It is recommended that red-colored type be used, not for aesthetic purposes, nor for variety, but rather only for calling attention to highly important information, such as to controversial statements, unusual copyright notices, important footnotes or other warnings to the reader of any sort. This is NOT to say that we must necessarily use it in such cases, but rather that we at least reserve it only for necessary situations. Otherwise, if we use red type aesthetically throughout the module, in headlines and other trivial things, the more oblivious the reader will eventually become to our important messages found in other parts of the module. If you insist on using red, blue, or any other color for your headlines, always opt for a dark version, as this will help avoid confusion, and will keep a strong, legible contrast against any light-colored background. Use maroon instead of red; dark blue instead of hyperlink blue, dark brown instead of tan, etc. The subtle difference between these colors and the black body text, may even give your module a little more class.

By the way, it would not hurt to remember that, while the authors of some of the finest works online may be brilliant theologians, they are not necessarily gifted with typesetting skills. In a sense, we should take the liberty of improving and dignifying the visual presentation of their works by simplifying the text to more traditional standards, by changing any non-essential text colors to plain black-and-white, by converting the silly, flowery, or juvenile typestyles so often used today to more conservative alternatives, and doing anything else that we can do to make the work look less like something from a teenager’s homemade website and more like a professionally-published book. In the long run, the author will appreciate the improvement, but the main advantage is that it will help make the module more legible and practical for use in TheWord.

Type size. Note: Costas wisely asks that we keep the body text at 10pt while headlines may be larger. This is not a rule, of course, but rather a plea for our cooperation, so that all modules originally open at the same size, and create an environment for smoother browsing, searching and reading. Otherwise the user will find himself zooming in and zooming out constantly, each time he opens a new user-module with sub-standard type sizes.

Text with embedded links. Oftentimes when we copy text from the Internet, such as from Wikipedia, the text comes with lots of embedded links of its own. This can be a blessing or a curse. It's a blessing if you want your reader to link to something on the original website, because you do not have to format it, as it is already linked. However, it could be a curse if it is a "table of contents" that you pasted into your module as an overview to what the module contained; users will eventually click on one of those items, thinking that the links are internally linked to the corresponding chapter within the module. To prevent this confusion, I suggest that you remove all unused links by selecting the affected text, and then selecting from the context menu "hyperlink"--> "delete hyperlink". Also be sure to delete embedded bookmarks that came over in the transfer, if they are not meant to be used in within the module.

Wrapping text to the window. I have recently discovered that inserting graphic images makes it nearly impossible for the text to "wrap to window." Some images can be set to automatically adjust to whatever the window width happens to be, but many of them simply cannot be tamed. Surely this will be corrected in a future version of the program, but meanwhile, it is an undeniable issue. Tables also create the same problem; once inserted, the window text no longer wraps.

This is no big deal for those users who enjoy using low, wide bookview windows, but for the rest of us who use tall narrow windows (three per screen, three columns in total), we prefer not to scroll except when necessary, in order to concentrate on reading. Therefore, you can do us a favor, not by omitting images and tables, but by using them only where needed. In other words, little adornments and dingbats ("printer's ornaments") at the top or bottom of any bookview pane, should be omitted, as they will have the adverse effect of preventing the text from wrapping to window width for the user. On the other hand, keep the nice charts and illustrations, as these have a function and practical purpose. By the way, if you have a table with just a few rows, why not consider using tabs with ellipses, instead of a true table? You know: like a typical "table of contents" in a printed book? Below is an example of how a simple table can work just as well with tabs and ellipses, for the sake of keeping the text flow intact:

Good kings of Israel........................Figure 10
Evil kings of Israel...........................Figure 20
Really rotten kings of Israel..............Figure 30
Beyond-rotten kings of Israel...........Figure 40

In conclusion, why use a table to prevent text wrapping when oftentimes a simple tabbed list will suffice? It will allow the text to flow more smoothly, and to wrap to the window.

Justified margins (but not sanctified). The following suggestion may really hurt your feelings. I am prepared for the worst. If you had told me, ten years ago, what I am going to tell you now, I surely would have argued the point.

I have worked in the graphic design/printing industry for years, and had always had a fondness for "justified margins" (i.e., when the body text is perfectly aligned on both sides of the printed page) When using a professional program like Adobe InDesign or Quark Xpress, one can adjust the kerning so that the justified margins look natural. Nevertheless, when using a word processor like Word or OpenOffice, kerning adjustments are usually not available, so you end up with large gaps between words, just to make the margins even--especially when working with narrow columns of text, such as in a newsletter.

TheWord was not created to be a professional layout program, but a Bible-study program. Text with justified margins in a bookview window is therefore usually imperfectly spaced and slightly harder to read than left-justified text. If one is to choose function over form, left-justified text is preferred, for the sake of better legibility and less strain on the eyes. The jagged edges that result, on the right side of the text, are not really an issue, as the text still remains relatively well spaced, within the bookview window. Personally, I wish that official premium modules were formatted in this way, as they would be easier to read for everyone. (For more information about justification, and the problems that it can present, read here: https://en.wikipedia.org/wiki/Typograph ... #Justified )

Paragraph indentations. Personally, I don't like using a first-line indentations for any paragraph anymore; I prefer to use “block style:” increased spacing between paragraphs to show where they begin and where they end. Still, the practice of using first-line indentations is not by any means obsolete, as you can see from modern printed books. If you want to indent in this traditional way, at least be sure NOT to do it as you used to do on a typewriter, but rather, to use TheWord's built-in formatting feature. In other words, do not insert four or five blank spaces at the beginning of each paragraph, but rather, select the entire text first, then right click, and then from the context menu open the "paragraph" item, to set your indentations globally, and modify them as the need arises.

Outline indentations. Anyone using the Guzik Commentary has already noticed that Guzik’s outline form makes the module harder to use. The empty spaces produced by the wide indentations diminish the quantity of visible text that can be read and used, requiring additional scrolling. All 969 chapters are like this. Meanwhile, other commentaries out there use an outline format but have omitted the indentations. In fact, all of the scholarly books that I have from the 1930s and before, followed the practice of using outlines but without indentations.

In the case of TheWord, this practice of omitting the indentations wherever feasible, results in a nice, compact text that shows lots of information in the same narrow bookview window, without sacrificing one word of the original content. The result is a window with tight text that does not have to be scrolled as much. My suggestion is that we follow that principle, as much as possible, in all of our user modules. Wherever indentation is absolutely essential to the style of the module, at least reduce the indentation to a bare minimum, please. In other words, instead of using five spaces, use just one. This will keep the module fairly compact even in narrow bookview windows.

Image resolution. When inserting graphic images into your new user module, I suggest using the minimum resolution necessary, all depending on the end purpose of the image. If it is merely a scan of an ancient drawing of Bethlehem, for example--not particularly useful in an age where the city has grown and better images are available online--I would say to keep the resolution as low as possible to view the image well on screen, but not in print. On the other hand, if your image is of a nice chart of the End-Times, or a diagram of the Tabernacle, or anything else that the reader would likely want to print or view in great detail, by all means, keep the resolution high, but only as high as necessary. The general rule of thumb is 300dpi at the desired print size. In other words, if most people would just print it out on a sheet of paper 8.5” x 11” in size, set that as your print size before setting 300 dpi as the resolution.

Grayscale vs. Color. Be careful not to make color scans of colorless images, as this inadvertently increases the size of the image file and, consequently, of the module. In other words, if your original image is in black-and-white, either scan it as such, or else, after you scan it, convert it to "black-and-white" or "grayscale." You can inform your scanner even before scanning, that the final image must be only "black-and-white" or "grayscale," thereby reducing the overall file size without sacrificing any quality whatsoever (you scan may also go faster). In other words, if you do not check this out beforehand, your scanner will assume that everything that you scan will be in color, and will save your image as a color image, although to the naked eye, there will be no difference; the scanner will interpret the most subtle shades of gray as light blue or beige, thereby doubling the pixel information embedded into the file. If it is a mere line drawing, save it as a bit-mapped image, but if it has shades of gray, as a "grayscale". Experiment between these two formats, to see which works best.

On that note, you may have scanned an ancient diagram or document, the paper of which is already beginning to yellow. If you look closely, you will see that there is no color in the image itself, but only on the paper, and only due to the aging. Who cares about the paper color when the image is what is important? Don't scan it in color, but in grayscale mode. Doing so will reduce the size of the file and of the module, without diminishing the quality of the image. You may have to increase the brightness and contrast in your photo editor, but it will result in a better image.

Roman numerals. I think that we should convert all Roman numerals (I, II, III, IV, etc.) to Arabic numerals (1, 2, 3, etc.), but only where convenient to do so. This is especially useful to do in the publication info, so that the modern reader does not have to calculate the year of publication, every time he reads it. Also, if your book has only ten chapters or so, and each one was originally numbered with Roman numerals, I suggest that you convert those to Arabic. If the Roman numerals appear only in the heading of each chapter, I suggest that you convert them. At the moment I know of no program that will automatically search-and-replace them, but when I hear of one, I will let you know.

Nevertheless, I am NOT suggesting to go through the text and convert every other instance of Roman numerals, such as in the older forms of Bible references (John III.xvi), but only in the title page, headlines, chapter headings, etc., and only if it is convenient to do so. Incidentally, those Roman numerals are hard for TheWord to recognize and to convert into links automatically using "Detect all verse references in viewer" from the context menu, so every little bit helps.

Unorthodox kerning. I have found some headlines in user modules, with one space between every letter, such as H E R M E N E U T I C S. I don't know how this happened, whether it was intentional or not, or whether it happened when the module was converted from one format to another, but I suggest that we not space any words in that way. To set them apart, we should rather use bold-faced type, or enlarge the point size of the type, but this kind of strange spacing makes the word itself difficult to re-adjust, and makes it IMPOSSIBLE to search for using "Book search view" (unless you just happen to remember that the word had all those extra spaces, and you type in the search query accordingly).

Bible text quotations within a commentary. Many commentaries quote the Bible text before making a comment on the passage in question. If the formatting of the quoted Bible passage is the same as that of the comment that follows it, it will take the reader just a little bit longer, as he reads through, to distinguish the comment from the Bible quote. In other words, as he generally begins reading at the top of the commentary window, after reading a few lines he sees that he is inadvertently re-reading the same portion of the corresponding Bible passage that he had just read in the Bibleview window. Now he has to continue skimming down through that text until he can finally locate the end of the quote and the beginning of the commentator's remarks. This happens again, and again, with every chapter, and sometimes with every verse, all depending on how the commentary module was formatted.

My suggestion is that we help the reader by putting the Bible quotation in bold-faced type, perhaps even in italics also, perhaps even in colored text, and if possible, that we separate the quotation from the comment, such as with a carriage return. This is quite an issue with the current Guzik commentary, as the author quotes every passage before commenting on it, and yet there is no distinctive formatting for those quotations (although a previous edition of the commentary had those quotations marked in green type, which helped). Below is a screenshot from the Clarke commentary, before formatting and after, where the quotations are made to appear in bold italics. Another fine example of nice, clear separation using bold italics can be found in Costas' own version of the John Gill Commentary module. There is also a screenshot above (in the section on “outline indentations”) of what could be done to the Guzik commentary by using only a distinct color to separate the Bible quotations from the commentator's remarks.

Background anomalies. Please remember that not everyone uses a plain-white background for his bookview reader (as you can see from the screenshots herein). Consequently, if you copy text from the Internet, it may often come accompanied by mysterious "highlighting" or invisible text that may not even appear when placed onto a white background--but only rather on a colored background. I have seen this often in the text pasted in the "about" tab. I suggest removing the formatting itself from the text, before pasting it anywhere, and applying your own preferred formatting after that.

Placeholder text, invisible hyperlinks, etc. Some module creators have created template modules, in which they use white "placeholder" text in the more common topics, which they will later fill with module text, as it becomes available. Unfortunately, they never get around to deleting the placeholder text, as they assume that it will be invisible to all users anyway. What they fail to take into consideration is when the bookview window's background is not white, but light blue, beige, or of any other color, that the placeholder text shows up clearly. Consequently, I would just offer a reminder to such people, to remove that text, once the module is complete. A nice check-list might be a good way to remember to do all these little things before preparing the module for posting.

On that note, it would be nice of us to remember, as we encounter less-than-perfect formatting in our modules, that some of the most excellent module creators are simply volunteers who are doing the world a wonderful favor by providing these texts for our use; their top priority is to provide the texts, while the formatting itself is secondary. Let us all be thankful for their work and avoid criticizing them altogether. We can usually take up the slack by improving upon the formatting ourselves.

Copying and pasting outlined text. When copying outlined information from the Internet, it is common for the text to copy well, but the outline labels to disappear altogether in your word processor. (This depends on how it was laid out on the source page). I recently discovered that by pasting such problematic text directly into the "new user module," rather than into my word processor, the outline labels are basically retained. Consequently, if you have any formatting to do after transferring the text, first paste it into the new module, then select and re-copy from the new module into clipboard memory (so that the outline labels will be copied as well), and then take it all over to your word processor, for the additional formatting. After the additional formatting, select and copy that text back into memory, and paste it back into your module. It sounds ridiculous, but it works.

Choice of fonts. Traditionally, printed materials have never used more than two or three typefaces per document, and in many cases, only one. For example, when they use only one, they may use Times New Roman throughout the body, and Times New Roman Bold for the headlines or chapter headings. If they use two typefaces, they may use Times New Roman throughout the body, but Futura Bold for the headlines, for example.

Using only one or two typefaces throughout your module helps your work to look neat, consistent, and credible. On the other hand, when one uses more than two or three typefaces in a document, his work begins to look disorderly, if not goofy, not unlike the old "ransom notes" made by pasting together letters of different styles from different sources. What is worse yet is when the module creator uses one type style for one chapter, and another, for the next; or when he uses one style for the headings on one page, but a different style for the headings on the next. The point here is to be consistent.

Also, as legibility is an important issue when preparing material for reading and studying, we should never use cursive or flowery fonts (such as Edwardian Script), nor juvenile styles (such as Comic Sans), as they are simply harder to read. Save your flowery fonts for your wedding invitations, and your juvenile fonts for your children’s handcrafts. Costas recommends using Tahoma for all modules, and I think that this is a good compromise.

Include all original publication data In other words, include the information typically found on the title page and the page that follows it, inside a printed book. In the "module properties" window for the module in question, there are three tabs, and the first is called "properties". On that tab you should include all the original data before uploading your module for distribution. The fields are already labeled, so all that you have to do is type them in. Below are the main reasons for which this is so important to the community of users.

1. Some authors will not allow us to use their material as a module without including all the original publication data inside. You could really cause trouble for us by failing to comply with their request.

2. In every case, including the publication data helps us to recognize, respect, and show our appreciation to authors who have spent hundreds of hours--if not years--writing and revising the original text that you are now formatting for us, not to mention, to their publisher.

3. If you include the publication data in your module, those of us who use your module can, in turn, cite that information in our own writings and sermons, and thereby prove to our own readers that we have done thorough research. We can include complete footnotes and bibliographies, for example.

4. Having that publication data available to us, to quote in our own writings, helps us to be transparent, to avoid accidental plagiarism, and to be more accountable for what we write. Many users of TheWord will not take your module seriously, and will not use it or recommend it to others, if they see that you did not bother to include the publication data, as the legal risks involved in professional publications would be too great.

5. Having the publication data available to us, to quote in our own writings, provides a trail by which our own readers can more easily locate your module online for downloading, or else, check the original source of our quotations. It also allows the readers to follow the path of our research, to see what contributions may have been made to the study before we even presented our own conclusions.

6. Having that publication data available to us, to quote, can help Christian writers to share the blame, when their conclusions based on works cited, are wrong. Otherwise, it can help us to prove that certain publications are faulty to begin with.

7. Plans are underway to allow users of a future revision of TheWord to quickly copy and paste all publication data instantly and automatically from any bookview module. However, if you do not put that publication information into the correct spaces to begin with, the feature will not work correctly.

Recommended Software for Creating, Formatting, and Converting Modules

E-mail stripper is a free program that eliminates 90% of formatting anomalies that are often embedded in the text that is copied from the Internet. Better yet, as you know, sometimes the text copied from a PDF or HTML does not even merge all the lines of a given paragraph, but leaves the right end of each line "hanging," requiring many manual adjustments. While there may be a better way to fix that than what I know of, E-mail stripper seems to remove all those "forced returns" without merging the selected paragraph with those above it and below it! I had been looking for years, for a program that would do that. So far, it has worked! (Note: the stripper program window has no button for "clearing" the current window content; you must simply paste onto whatever is already in the window and the previous text will be removed automatically; then, of course, you click "paste" and then "copy" to copy the new raw text back onto your clipboard. Your paragraph markers will not be removed, keeping the paragraphs separated always, apparently.) Download here: http://www.papercut.com/emailStripper.htm

Jarte is another free program which works as a good substitute for "Word Pad" or "Write", and often retains the formatting when copying back and forth from the module window. What is better, it has only two useful search-and-replace functions that you will not find in many other programs: namely, you can use meta-characters as your search criteria (like{c}for "hard or soft return") to search and replace excess spacing between paragraphs! I typically perform a function like "Please search for {c}{c} and replace with {c}" as this will keep your paragraphs intact while removing all "double-spaces" between them. (If you have four blank lines anywhere in the document, you could then repeat the same operation a second time. Remember as I mentioned above, I recommend eliminating all spaces altogether from between your paragraphs--but without merging the paragraphs--and that you use instead "paragraph formatting" from the context menu within TW to create global separations with just a few clicks).

Also, with Jarte you can also search and replace or eliminate any and all excess tabs using a similar operation (hidden behind the gear-wheel icon). Sometimes I have 1,000 pages of text in which every paragraph begins, not with a tabbed indentation, but with a five-space indentation. I simply type five blank spaces into my "search" window and none into my "replace" window, and hit "replace all." In this way I can instantly fix the problem throughout all 1,000 pages of text with one click. Download the free program here http://www.jarte.com/download.html

For other search-and-replace options, I am still on a quest for the ideal program. I have my eyes on a commercial program called Text Pipe, but so far, I have no information about all that it does. The process is often referred to as "text manipulation." Many programs may be useless in general, but offer a few unique features regarding text manipulation that others do not offer.

Consequently, I never discard any one program too hastily; each one can be useful for one operation or another. While preparing modules, I use Jarte only for those two operations mentioned above (deleting all tabs or excess carriage returns).

OpenOffice Writer is a free program comparable to Microsoft Word, WordPerfect, and other word processors. It is very useful for some of the more complex text manipulation that you may do in the preparation of a module, but if you already have Microsoft Word or WordPerfect, those will perform the same tricks. (The only advantage to OpenOffice is that it is free). An example of more advanced manipulation would be the using of styles, for example: finding any centered paragraph of text that uses green, bold, italic Times New Roman, and replacing it with left-justified, black, plain text in the Arial typestyle, all in just a few clicks.

As mentioned above, you can also use this program to change the "case" of any text, from "all caps" to "title case" or to "sentence case" or to "lowercase," for example, to alphabetize lists of information (using the "sort" command), to create tables, or more often, to remove existing tables and convert the content into ordinary text; in fact, sometimes all you want is the 300 lines of text from one column in a table that you found online; in such a case you can paste the table into OpenOffice, remove the undesired columns, and then convert the remaining column into plain text. Download the free program here: http://www.openoffice.org/download/ Be sure to download the "alternative find-and-replace" plug-in for OpenOffice, separately: http://extensions.openoffice.org/en/pro ... -altsearch

Adobe Indesign or Quark Xpress. These are expensive programs used for professional typesetting, but they have features for even more complex text manipulation than what was mentioned above. Personally I recommend the "story editor" in Indesign and whatever they call it in Quark Xpress. Both programs cost upwards of $300 each, I believe, but you may find an older second-hand edition for about $100, if you think you need it. Microsoft Publisher seems to be a simplified imitation of both of these programs--just to give you an idea--but the general principles are the same. Any version of Indesign will have the features I mentioned.

Calibre is a wonderful free program that Josh Bond introduced me to, and it is also free of charge. This program does many things, but the part that I most like is converting e-books that you may find online (such as PDFs) into ordinary text files (such as TXT), so that they can more easily be converted into modules. You can convert from any of the following source formats: AZW, AZW3, AZW4, CBZ, CBR, CBC, CHM, DJVU, DOCX, EPUB, FB2, HTML, HTMLZ, LIT, LRF, MOBI, ODT, PDF, PRC, PDB, PML, RB, RTF, SNB, TCR, TXT, TXTZ You can export your file into any of the following formats for the output: AZW3, EPUB, DOCX, FB2, HTMLZ, OEB, LIT, LRF, MOBI, PDB, PMLZ, RB, PDF, RTF, SNB, TCR, TXT, TXTZ, ZIP. Best of all, the program that does all this is free. Download it here: http://calibre-ebook.com/download

GIMP 2.8. For your graphics editing and photo re-touching, for preparing charts and diagrams, don't spend money on Photoshop, but rather, download the free, sophisticated photo-editor called GIMP 2.8 which does most of what Photoshop does, but for free! Download it here: https://www.gimp.org/downloads/ I spent many weeks comparing all the free photo editors available, and this was, by far, the best compromise between ease of use and function.

PhotoFiltre 6.5.3 is another photo editor, more limited than GIMP but much easier to use. If you intend only the simplest re-touching, or you have never done much re-touching in general and are afraid to get in over your head, you may prefer the simplicity of PhotoFiltre. Download it here: http://photofiltre.free.fr/utils/pf-setup-en-653.exe

TextBridgePro If you are going to scan printed pages and convert them to digital text for the purpose of making new modules, you need some type of O.C.R. software (= Optical Character Recognition software). I used to use a commercial program called TextBridgePro, but it has been years, and the technology and quality of the results may have improved since then. In fact, there are surely better programs by now. There are a few free programs on the Internet that use the same old OCR engine as TextBridgePro but with a different "front-end" and interface. You may not have realized it, but, many scanners come with light versions of even better programs, so you may want to check to see whether you already have an OCR program included with your scanner, which would likely be found on your installation disc.

Abbyy Finereader. If you want the very best O.C.R. software, Brother Josh Bond recommends "Abbyy Finereader," but apparently it comes at a price of about $170. http://www.abbyy.com/finereader/professional/. I don't have the names handy of the freeware that does this, so please search online, in the meantime.

SQLite RegExer 2.3 Raymond Barone was so kind as to develop and provide for us a program called SQLite RegExer 2.3, which can be used to perform Regular Expression find and replace on un-encrypted e-Sword and theWord modules. It can also be helpful for making GLOBAL changes to existing modules, or for re-formatting them, such as increasing the font size for all chapters globally, even if they have already been divided into 100 separate topics and subtopics. Note: you have to decompress the module and convert it to RTF before using this program.

To quote Raymond, other features include the following:

1- Increase or decrease the font size in the whole module using the "RTF Text Resize" button:
2- View and edit any table in the module:
3- View and edit the content of any item in the table:
4- Search for a regular expression in any column in a specific table in the file:
5- Compact the database or drop a table:
6- Execute a non-query SQLite statement:

Raymond provides links to the older version as well as the new, so just download the new version, 2.3 here: Non-programmers, fear not, as he also offers detailed instructions. Download the program, read the information, and send Raymond a "thank you" here: http://www.biblesupport.com/e-sword-dow ... e-regexer/

Thanks to JG (Jon) for this great tip.

TW Importer tool. This small program is a creation of Costas Stergiou, the creator of TheWord. It is used to convert existing modules for other Bible-study programs, into TheWord format. This program and other utilities like it, can be downloaded here: http://www.theword.net/index.php?articl ... &l=english.

E-Sword Tool Tip Tool NT.Brent Hildebrand created a very popular program for creating modules, not for TheWord but for E-Sword. The program is called E-Sword Tool Tip Tool NT. People rave about it. You can use it to do things for module preparation that you may not be able to do with other programs, and then convert your finished product using the TW Importer tool mentioned above. (But consider saving a copy of your E-Sword version first, to share with E-Sword users, before proceeding to convert it into TW format, as there does not seem to be any way of converting in reverse) Josh Bond has created a quick link for downloading E-Sword Tool Tip Tool NT here: http://goo.gl/93EDr Josh also provided a link to the manual for that program, available here http://www.biblesupport.com/e-sword-dow ... n-1052013/ For a nice, general introduction to the program, see Dr. Dave Thomason's website here: http://www.doctordavet.com/t3instructions.html

Duplicate Lines Remover. I have discovered a free program that simply goes through any text document and removes any duplicate lines of text. How nice! This can be a useful step toward preparing the text to later become a module, especially if you just copied long lists from different sources and compiled them into one long list to use in a module; you may easily have duplicates there, and this program will remove them. It is called "Duplicate Lines Remover" available here: http://www.softpedia.com/get/Office-too ... over.shtml It can also alphabetize your lists before removing the duplicates.

As for any other freeware that you may need, for general word processing and text manipulation, there is always a good chance of finding something useful at Gizmo's Freeware site, at http://www.techsupportalert.com. The nice part is that most of what they recommend is evaluated by other users in their forum, and has already been tested for viruses, advertising, tricks, traps, and so on.

Meanwhile, please pray that other legendary module-makers such as Josh Bond, David Cox, and Dr. Dave Thomason, will add to this post their own list of formatting suggestions and recommended software, sometime soon.

More coming soon. Meanwhile, take a look at the screenshots below, that illustrate some of the points mentioned above. This post is revised about every three weeks, so please check back for more tips.

Incidentally, my list of "seven reaons for including publication data for academic citation," presented above, is based loosely on the articles listed below, that I found online. I list them here only for the sake of properly documenting the sources:
http://library.uvm.edu/guides/citation/why.php
http://libguides.mit.edu/citing
https://falconediting.com/en/blog/6-rea ... en-writing
http://libguides.usask.ca/citation/whycite
http://www.concordia.ca/students/academ ... grity.html
https://www.qub.ac.uk/cite2write/harvard.pdf
http://www.ibo.org/globalassets/digital ... ing-en.pdf
http://lib.dmu.edu/su/ethicaldoc/whycite


.


Attachments:
title page BEFORE sm.jpg
title page BEFORE sm.jpg [ 120.36 KiB | Viewed 1958 times ]
title page AFTER.jpg
title page AFTER.jpg [ 136.89 KiB | Viewed 1958 times ]
guzik sm.jpg
guzik sm.jpg [ 287.85 KiB | Viewed 1958 times ]

_________________
.
I'm an Independent Baptist running TheWord portable v 5.0.0.1481 from an external 500GB hard drive with over 1,900 modules installed and loaded in my current module set. I'm using 32-bit Vista Ultimate SP1 with a 2.7gHz processor and 4GB RAM.
.


Last edited by ErikJon on Wed Feb 08, 2017 3:00 am, edited 60 times in total.

Wed Jan 06, 2016 4:55 am
Profile

Joined: Thu Nov 08, 2012 10:24 pm
Posts: 418
Post Re: Tips for formatting new user-modules
1.Screenshot of the proposed 'about" tab
2.Illustration of problems to be avoided with paragraph spacing and leading (line spacing).


Attachments:
tight.jpg
tight.jpg [ 441.56 KiB | Viewed 1702 times ]
tw.jpg
tw.jpg [ 670.05 KiB | Viewed 1702 times ]
about tab sm.jpg
about tab sm.jpg [ 132.24 KiB | Viewed 1958 times ]

_________________
.
I'm an Independent Baptist running TheWord portable v 5.0.0.1481 from an external 500GB hard drive with over 1,900 modules installed and loaded in my current module set. I'm using 32-bit Vista Ultimate SP1 with a 2.7gHz processor and 4GB RAM.
.


Last edited by ErikJon on Mon Feb 22, 2016 4:47 am, edited 3 times in total.

Wed Jan 06, 2016 6:06 am
Profile

Joined: Thu Nov 08, 2012 10:24 pm
Posts: 418
Post Re: Tips for formatting new user-modules
Re: screenshot of Dr. Peter Pett's Commentary below: Somebody copied some nice biographical or background information regarding the commentary, and pasted it into the module properties window. Unfortunately, some background-color was inadvertently copied along with the text, making it impossible to read. This would not be a problem to correct, had the module creator not locked the module permanently. Now, the only way to correct it is to notify the module creator, wait for him to correct it and upload it, and then download it again. Heaven forbid that we should have already marked many chapters with underlining and highlighting, as the new upload will lose all of that data. The more practical solution is not to lock your module at all, if not absolutely necessary, so that others can make minor improvements, correct spelling mistakes, remove anomalies like this one has, and so on.

Re: second screenshot below: Bible quotations within commentaries can be set apart with bold italic text and some separation, to make it much easier to identify quickly which is the quotation and which is the comment from the author. Costas has done an excellent job of making that distinction throughout his John Gill Commentary. For a work in progress along these lines, see also the Guzik "before" and "after" screenshot above.


Attachments:
barclay 1+2+3.jpg
barclay 1+2+3.jpg [ 845.07 KiB | Viewed 688 times ]
TW pett.jpg
TW pett.jpg [ 263.33 KiB | Viewed 726 times ]
COMBINED.jpg
COMBINED.jpg [ 289.45 KiB | Viewed 1702 times ]

_________________
.
I'm an Independent Baptist running TheWord portable v 5.0.0.1481 from an external 500GB hard drive with over 1,900 modules installed and loaded in my current module set. I'm using 32-bit Vista Ultimate SP1 with a 2.7gHz processor and 4GB RAM.
.


Last edited by ErikJon on Wed Feb 08, 2017 2:57 am, edited 7 times in total.

Wed Jan 06, 2016 6:09 am
Profile

Joined: Fri Sep 03, 2010 3:07 am
Posts: 29
Post Re: Tips for formatting new user-modules
This is good stuff!

_________________
WordModules.com
Large, reference modules for Evangelical Christians. 100% Free. No strings attached.


Wed Jan 06, 2016 7:25 pm
Profile
Site Admin

Joined: Tue Aug 29, 2006 2:09 pm
Posts: 8542
Location: Corfu, Greece
Post Re: Tips for creating, formatting, and converting new module
Great stuff yes. I would go so far as to suggest that this info is also merged in the first official doc and create a standarized 'best practices' document
Erik, what do you think? Could you undertake this task?


Sat Jan 16, 2016 3:36 pm
Profile WWW

Joined: Thu Nov 08, 2012 10:24 pm
Posts: 418
Post Re: Tips for creating, formatting, and converting new module
.
Yes, I'll be happy to do that.

I will combine them, remove any overlap, and send a copy to you for approval.

If you are aware of any similar posts on the forum, that I could include in the consolidated document, let me know.

I suggest that we save the new finished document in PDF format, rather than DOC, so as to preserve the formatting and make it easier for everyone to open. Is that O.K. with you?

Meanwhile, please tell me how to include tags on this post above, or make it sticky, or whatever you would like to do, to make it easier for other people to find.
.

_________________
.
I'm an Independent Baptist running TheWord portable v 5.0.0.1481 from an external 500GB hard drive with over 1,900 modules installed and loaded in my current module set. I'm using 32-bit Vista Ultimate SP1 with a 2.7gHz processor and 4GB RAM.
.


Sat Jan 16, 2016 7:28 pm
Profile

Joined: Thu Nov 08, 2012 10:24 pm
Posts: 418
Post Re: Tips & Software for creating, formatting, converting mod
.
Costas,

I know you are busy.

Just to remid you that I finally sent you TWO versions of the new combined document, in OpenOffice format. You wrote back to me, about the first version, but did not acknowledge the second, and since the link to your original DOC file is still old, I assume that you have not had time to work on that.

The second version was an improvement on the first, so I hope you discard the first version that I sent you.

If I had known that you specifically wanted Word format for this document, I would have created it in Word, from the start, but since I use OpenOffice for everything, I did not do it. Since I had not expected to convert it to PDF anyway, I did not think it would matter which program I had used to make it. Now, if I convert it into Word format, some of the formatting is ruined, so I just sent you the OpenOffice version, in the meantime, since I did not have time to re-format the whole document again in Word. If that version is good enough for you, you can easily export it to PDF with a built-in converter in the "file" menu, or else use any PDF virtual printer.

Incidentally, I copied all the text from this second revision, and re-posted it above, here in the forum, so the whole post is now updated, as noted in the headline.
.

_________________
.
I'm an Independent Baptist running TheWord portable v 5.0.0.1481 from an external 500GB hard drive with over 1,900 modules installed and loaded in my current module set. I'm using 32-bit Vista Ultimate SP1 with a 2.7gHz processor and 4GB RAM.
.


Wed Jun 22, 2016 6:39 pm
Profile
Site Admin

Joined: Tue Aug 29, 2006 2:09 pm
Posts: 8542
Location: Corfu, Greece
Post Re: Tips & Software for creating, formatting, converting mod
Erik,
you are correct, I am just late (as always). I will be out of office for the next 4 days, so I will get back to it next week.
Costas


Thu Jun 23, 2016 7:03 am
Profile WWW
Site Admin

Joined: Tue Aug 29, 2006 2:09 pm
Posts: 8542
Location: Corfu, Greece
Post Re: Tips & Software for creating, formatting, converting mod
Just to let everyone know: Erik's update document has been posted here: http://www.theword.net/index.php?articl ... &l=english and especially at this link:

http://www.theword.net/docs/tw-module-c ... elines.pdf

Costas


Thu Jun 30, 2016 9:48 pm
Profile WWW

Joined: Thu Nov 08, 2012 10:24 pm
Posts: 418
Post Re: Tips & Software for creating, formatting, converting mod
Friends,

I've just discovered a similar thread to this one--albeit much shorter--from a brother named Aaron in Dallas. You may wish to check it out. It is located here: viewtopic.php?f=2&t=553&p=37046#p37046

_________________
.
I'm an Independent Baptist running TheWord portable v 5.0.0.1481 from an external 500GB hard drive with over 1,900 modules installed and loaded in my current module set. I'm using 32-bit Vista Ultimate SP1 with a 2.7gHz processor and 4GB RAM.
.


Tue Dec 27, 2016 9:51 pm
Profile

Joined: Wed Sep 29, 2010 10:04 pm
Posts: 302
Post Re: Tips & Software for creating, formatting, converting mod
May I add that information that is in regards to bibliographies, author, title, publication date, publication location, etc. be included for each module. Also when something like original authorship is left out it can appear as if the module creator made the material on his own. This could look like plagiarism.

This information helps in the aspect of writing papers for seminary studies, etc. Perhaps this could be done in a feature like kindle has which includes this information when copying from a book.

For example:
"Such training and admonition would be sensitive to the children’s responses and needs."
Hoehner, Harold W.. Ephesians: An Exegetical Commentary (Kindle Location 15801). Baker Publishing Group. Kindle Edition.

Here is another example from a foot note in a paper.
Hoehner, Harold W., Ephesians: An Exegetical Commentary, Kindle Edition (Grand Rapids, Michigan: Baker Publishing Group, 2002).

This information is important for academic research or if you want to go back in your studies to a specific edition of a specific book, etc.


Last edited by jonathangkoehn on Fri Jan 27, 2017 7:45 pm, edited 4 times in total.



Fri Jan 27, 2017 2:03 am
Profile

Joined: Thu Nov 08, 2012 10:24 pm
Posts: 418
Post Re: Tips & Software for creating, formatting, converting mod
You are certainly right, Jonathan. Users have already suggested that feature on the forum, and I second the motion, myself.

Here is one
viewtopic.php?f=3&t=2246&hilit=citation

Here is another
viewtopic.php?f=2&t=4375&p=27961&hilit=citation#p27961

In a few minutes, I will write my own observations on this issue at the second link, as that thread is more directly relevant to academic citation than the issue of formatting, on this page.

_________________
.
I'm an Independent Baptist running TheWord portable v 5.0.0.1481 from an external 500GB hard drive with over 1,900 modules installed and loaded in my current module set. I'm using 32-bit Vista Ultimate SP1 with a 2.7gHz processor and 4GB RAM.
.


Fri Jan 27, 2017 7:00 am
Profile

Joined: Wed Aug 20, 2008 3:50 pm
Posts: 160
Location: Mexico
Post Re: Tips & Software for creating, formatting, converting mod
I came across a youtube video on making a Bible from Online Bible -> text file -> theWord -> MySword. If you stop at theWord, it is great for our community.
https://www.youtube.com/watch?v=jPupNk5u864

David Cox

_________________
In Christ,
Pastor David Cox
davidcox (at sign) davidcox.com.mx


Mon Jul 31, 2017 11:31 pm
Profile

Joined: Thu Nov 08, 2012 10:24 pm
Posts: 418
Post Re: Tips & Software for creating, formatting, converting mod
Thanks, brother Dave, the Master Module Builder.

In fact, that was just what I was looking for for MySword. I can think of five Bible modules that I need badly on MySword, which I already have on TheWord and Online Bible. Great timing.

_________________
.
I'm an Independent Baptist running TheWord portable v 5.0.0.1481 from an external 500GB hard drive with over 1,900 modules installed and loaded in my current module set. I'm using 32-bit Vista Ultimate SP1 with a 2.7gHz processor and 4GB RAM.
.


Fri Aug 11, 2017 6:58 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 15 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by STSoftware for PTF.