Christos has been working on our new web based word processor -Wax 2. It is based on the best of breed ProseMirror open source libs. A week or two ago Christos integrated a code editor (CodeMirror) with it and sent me the following vid…looks great (see below). We also have a similar feature in Wax 1, but the integration isn’t as nice… check out the last bit of the video where Christos is ‘undoing’ items. It works seemlessly. In Wax 1 the code editor is a separate embedded object to the parent page so the ‘undo’ history does not integrate as nicely as it does here..
Paged.js is the open source pagination engine we are developing to support CSS pagedmedia specifications. The development has progressed pretty fast, we only started it in Feb of this year. So far we know of one commercial product that has integrated it and several really interesting open source projects. It has also been used to make its first print book (the Editoria manual made in a Book Sprint last month). We don’t consider it near a 1.0 yet so this is pretty impressive!
We had one workshop in San Francisco last month. It was more of a paged.js core team meet really as it was a day after the Editoria community meeting and we didn’t really advertise it.
At the end of this month there is a workshop (2 days) in Paris and one in Brussels(1 day). We have 46 people enlisted. It is close to our max. There might be a few seats left (it is a free workshop), so if you want to go then sign up here –https://www.pagedmedia.org/pagedmedia-prepostprint-workshop/
Demand seems pretty high as we have had several people that can’t make either date asking us to keep their names for the next one. We also have folks coming from the Netherlands and the US to attend. Pretty cool!
But stay tuned… we will have more workshops including NYC sometime in March and a few surprise other countries on the list… I’ll keep you posted!
Guess what I brought in Morocco and are trying to get home… carrying it like a delicate baby through airports across the globe..
Heres a clue to help you narrow it down…incorrect answer number 1:
Every month I go to Athens to work with the Coko platform dev team. We talk through platform issues and set the months roadmap. I just met with them a few days ago. They are an awesome team. It deserves mention that pictured below are four folks and between them develop and maintain no less than four publishing platforms – Editoria, xpub-collabra, Micropubs and Wax. Incredible.
Highly productive and also amazing to work with.
36 Feature Proposals and a lot of discussion and here we have it..
- Color code tracked changes by user
- Configure book builder to omit blue buttons
- Indenting chapters in book builder
- Error message when uploading incorrect file format
We will not use an error message, rather we will constrain the upload dialog to display only available docx files.
- Author Style
- Provide a larger text box for inputting figure captions
https://gitlab.coko.foundation/editoria/editoria/issues/216 Category (2)
- enable “read only” chapter mode
- Autocomplete for adding book team roles
- Always show chapter name
- Book-level (and perhaps chapter-level) metadata
We will start this off as a simplified version of the proposal with book-level metadata. At this moment we will provide a mechanism to store and edit this metadata, but the list will not be comphrensive, nor will it export (yet) to any formats. We essentially wish to get this in place so we can all try it and add further sophistication in a future road map process.
- Configurable archive options for completed / abandoned books
We will focus on basic archiving options. No integrations yet, this will come in later roadmaps.
- Toolbar button to change case
This will be implement as a drop down (add to existing drop down semantic styles) as there are multiple options hence a single button is not sufficient.
- Usernames allowed with special characters
- Ask for first name and surname on sign up
- Kill automatic numbering in numbered list style
This might turn out to be harder than expected. We will try and fix this y working on a few fixes in the importer (XSweet) and then see where we are. Category (3)
- Allow components to move from body to front- or backmatter and vice versa
Harder than you might first imagine as it requires quite some reworking of the Book Builder code.
- Add more information to the “Books” dashboard and make it sortable
Will be built to extend the existing Dashboard components (making it more useful for other PubSweet projects).
The craziest thing just happened. I went to Morocco and the weekend I traveled the Moroccan government decided to cancel daylight savings. It was apparently at short notice. Consequently my phone was outa whack with the local time and I had to switch off the auto timezone and fix it manually…y’know, like the old days.
Then my watch, where I can set the cities and it auto updates was also outa whack and I had to do the same. I didn’t bother changing the time on my laptop because I don’t rely on that clock too much – it takes more than the absolute minimum amount of effort to update and when I am traversing many timezones in a short time its just a hassle.
Then a week goes by and I travel to Athens. My watch I can’t work out cause I turned the auto daylight savings off when i was in Morocco and then I couldnt work out why it was showing (what I thought) was the wrong time in Athens. Im only here for a day and a half, I didn’t care. So my laptop and my watch times can’t be trusted, no worries….I’ll go by my phone. I turned it to auto but it seemed wrong…sometimes when you land the phone networks take a while to update so I just turned it back to manual and updated it to what I thought the time was. But I was, for some crazy reason, an hour out. I don’t know how it happened… maybe it was cause I landed at 1am (or was it midnight?) or something. I don’t know…but I thought it was right.
So… no problems … I have a few meetings online from the hotel…no worries, when you travel a lot it doesn’t actually matter what timezone your calendar is set to – you just check the red line for the time now, and see when in the near future the meeting will be. No problems..I can work fine that way. Time being a relative thing and all when on the move, its not so much what time is it now but how much time to X (boarding…the hotel…sleep…a meeting) that is important.
Until… I sorta make a big deal, jokingly, about meeting later that day with the Coko Athens team… like, I traveled 17000 km and can make it to a cafe on time, but Yannis says he will be 20 minutes late going across town…or something like that…so I kinda give him a bit of a ribbing and make a big deal out of it…
I turn up to the cafe and everyone is there…I thought I was 10 mins late so I apologize… we have our meeting and all is good. The next day I have another meeting with them and they are all there on time (or so I thought) and we go through some more stuff, have some coffee…etc…
Then its time to go to the airport. I order a taxi and in the taxi see a clock on the dash… wait a minute…. its an hour later than what my phone says…I ping Yannis and ask him if I was 10 mins late for that first meeting…or if I was an hour late (horror!) … an hour late he says…both days….
oh my… can’t believe it. I hate being late and I turned up late twice. BY an hour! Worse that the very kind Greek team didn’t even mention it even though i had hassled them about getting there on time… I still can’t quite believe this happened….amazing…
Proposals now closed. Below is the synopsis of each proposal, cut and pasted from GitLab. Titles link to the GitLab issue. I didn’t copy across any images, so where you see a reference to an image, please check the original item.
All items can be found in GitLab also of course:
Create an account here: https://gitlab.coko.foundation/
Feature request: Please display tracked changes in different colors by user.
The request originates from UCP for Editoria, where only three users are expected to be within a given book/chapter editing at any given time.
Suggest retaining the tooltip, too, but adding this additional ‘at a glance’ feature to allow editors to quickly see who entered which tracked change within a longer book where checking each change by tool tip would become time consuming.
Org: Book Sprints
User story: As an author, I want to review a chapter while someone else is editing it.
To do this, I’d like to click on a read-only link for each chapter in the book builder. It doesn’t matter about the layout of the content, it just needs to be readable so that I can read it without having to render the entire book. No edit tools or comment tools are necessary, just a read-only version. As many people as needed should be able to click on the read-only view. Ideally, the read-only link should appear next to the edit button, and be permanently available (no permissions necessary).
Org: Book Sprints
User story : As an author, I want to be able to see the difference between parts and chapters at one glance.
To do that, it would be great to indent the chapters more so that the difference is more easily visible.
Org: Book Sprints
User story: As an author in a Book Sprint, I want the book builder to look as much as a table of content as possible. We do not upload word files in a Book Sprint, so we have no need for the blue buttons showing the upload status, therefore this UI element is unnecessary and distracting.
We would like to have the option to omit the blue buttons.
punctum books proposes an autocomplete feature when typing in names for book team roles (see attached image)
For example, when one of the possible users is Vincent it would be great if when I type Vinc it already suggests the rest of the name. Especially with large teams, this can be useful because you may not remember the exact spelling of each team member.
In the overview of Users under the Users menu include the different roles these users fulfill in the different Books
For example, under Username Vincent I would see Production Editor of followed by a list, Author of followed by a list, etc. This allows a quick review of which Users are involved in which Books.
punctum books proposes: an error message when you try to upload a file format that is not DOCX (such DOC) rather than XSweet trying to process it and then crashing.
punctum books proposes a toggle for invisible characters in the Wax editor.
This would allow quick discovery of double spaces, returns instead of enters, correctly inserting em/en spaces, weird tabs, and so on.
punctum books proposes: An additional Wax paragraph style “author.”
punctum books proposes that Wax automatically uses typographer’s quotes (for now, until there is proper language control).
When typing single or double quotes in Wax, they are not formatted as typographer’s quotes
punctum books proposes a feature that makes sure that the chapter name is always shown somewhere on the top of the page, so you know where you are.
punctum books proposes that usernames with underscores, periods, etc. are allowed.
Currently, it appears that no such usernames, such as “John_Doe” or “Paul.Smith” are allowed. When you try to create them, you get a 400 error without any further explanation.
punctum books proposes that new users are asked for first name and surname on signup.
Currently the only way to distinguish users is by username, and this becomes quickly problematic as the number of total collaborators on all book projects increases, especially if at some point users will start to make their own usernames which may not be directly comprehensible to Production Editors.
Registering first names and surnames allows for a better way of organizing users on the Users page.
Proposed by University of California Press
Adding sequential numbers to text styled as a numbered list would be helpful if one were authoring in Editoria. However, authors who want a list numbered submit it that way in .docx files, so the automatic numbering feature in this style adds a duplicate set of numbers to list items.
Proposed by University of California Press
To move to the next stage of testing and put a whole book through Editoria, we need styles for frontmatter components and a few more backmatter ones.
I’d like a separate section each for front- and backmatter styles in the vertical styling toolbar, with the former at the top and the latter at the bottom. There do not need to be too many styles in each of these lists, since the styles in the other sections (display, general text, lists) should be context-sensitive (e.g., for backmatter level-head, use Heading 1).
Because the front- and backmatter styles are rarely used in body components, it would be great if those style lists could be collapsed. They should still be available because there are instances where one might want one of those styles in a body component (e.g., in an edited volume, you might have bibliographical listings at the end of a chapter).
FRONTMATTER Here are the (most of the) styles we need that are not currently accounted for in the other lists (I am not including toc styles–that’s coming in another feature request):
Half Title Title Subtitle Author [if Barbara’s proposal of adding an author style is implemented, I assume it would be in Display, and we could just use that] Publisher
Series Title Series Editor Series List
For the rest of the elements in frontmatter, we could use styles in other sections (on output, the system would impose the frontmatter versions of these elements):
BEP Book Prose Epigraph —> Epigraph: Prose
BEPSN BEP Source Note —> Source Note
BEPO Book Poetry Epigraph —> Epigraph: Poetry
BEPOSN BEPO Source Note —> Source Note
FMH Frontmatter Head —> Title
FMAU Frontmatter Author —> Author
FM1 Frontmatter 1 Head —> Heading 1
FMTXT Frontmatter Text —> General Text
FIL Frontmatter Illustration List —> Numbered list
BACKMATTER Here are the (most of the styles we need that are not currently accounted for in the other lists:
Bibliography Glossary Contributor list Index
For the rest of the elements in backmatter, we could use styles in other sections (on output, the system would impose the backmatter versions of these elements):
Appendix Number —> Number [assuming we add a number style to Display]
Appendix Title —> Title
Appendix Subtitle —> Subtitle
Backmatter Head —> Title
Backmatter 1 Head —> Heading 1
Backmatter 2 Head —> Heading 2
Backmatter 3 Head —> Heading 3
Backmatter Text —> General text
Backmatter Prose Extract —> Extract: Prose
Backmatter prose extract Source Note —> Source note
Backmatter poetry —> Extract: Poetry
Backmatter poetry Source Note —> Source note
BM Numbered List Extract —> List / Bulleted
BM Unnumbered List Extract —> List / Unnumbered
BM Bulleted List Extract —> List / bulleted
Chronology —> Hoping we can add Chronology as a List style
Backmatter Abbreviation List —> Hoping we can add Abbreviations as a List style
I realize there’s a lot here. Please let me know if clarification or rethinking is needed. Thanks!!
Proposed by the University of California Press
Although authors usually provide a toc with their manuscripts, we would like one to be generated from the book components. I do think a placeholder needs to be present in the book builder so it can be specified for pagination. It could say something like “Table of Contents will be generated on final output.”
For frontmatter, toc should include every component that follows the toc and use text with the style Title.
For body text, toc should list chapter number and text styled as Title, Subtitle, and (if there is one) Author.
For backmatter, toc should include every component and use text with the style Title.
When a book has backnotes (most of our titles), it is sometimes a little tricky to figure out where they go (they could be preceded in the backmatter by appendixes, abbreviation lists, etc.), so maybe the easiest thing to do is add a placeholder component to the backmatter with the heading Notes styled as Title and boilerplate language saying something like “Backnotes will be gathered here on final output.” That way, we could specify placement, pagination, and the title could pull into a generated toc.
Proposed by University of California Press
Authors often format display type in all caps. If the design specifies title case, we need to specify how letters are treated (e.g., articles and prepositions lowercased)–it is an editorial decision, not one that can be automated. Right now, the only option seems to be to retype text to remove cap formatting. It’s time-consuming and a chance for introducing errors. Word’s options are uppercase, lowercase, sentence case (first letter only capped), and title case (first letter of all words capped–gets you most of the way there).
Proposed by University of California Press
Display component names in Book Builder in roman, not italic, type (italic type really shouldn’t be used unless there is a reason). Allow italic type to be within the name. See, e.g., in UCP deployment Wickes / Bible and Poetry** chapter 1 title: Ephrem’s Madrashe on Faith in Context.
Proposed by University of California Press
The revealed spaces between words make longer sections of inserted text difficult to read. Could we have a toggle to show these or not?
This is a placeholder feature proposal. Right now, Editoria expects camera-ready artwork to be placed inline in order to become a part of the book. At the moment, a caption can be included with the inserted artwork, but no additional metadata about the image. This feature would allow a user to insert artwork from a media library. The media library would be similar to WordPress’s media library and allow for media to be uploaded and inserted inline in a book via the Wax editor, which would then become part of the media library, or to be added directly to the media library. The media library would allow for some basic media editing as well. It should be a “media” library rather than an image library because ultimately Editoria should be able to support multimedia in addition to static images.
- Page dimensions (translates to book trim size)
- Display and text fonts
- One or two-column designs
- Various other differences
This is a placeholder feature request for Editoria to validate EPUBs produced by the system using the open source Epubcheck validation tool to validate the EPUB output for adherence to the EPUB standard.
This is a placeholder feature request for a mechanism to add a book and/or chapter-level metadata data entry mechanism to Editoria. This could be achieved either by integration with an API or export-drive feed from a publisher’s existing title management system or by adding a form to Editoria that would allow for the entry of this metadata. In some cases, this metadata will need to be added to create a valid EPUB file, so an MVP could include just those metadata elements necessary to create a valid EPUB. This would also be useful for output and distribution to other systems (e.g. a publisher’s digital asset management system).
This is a placeholder feature proposal to develop tools for validating EPUB outputs against accessibility guidelines as codified by the W3C and other standards organizations. This could include anything from validating the inclusion of alt-text and alerting users to missing alt-text for images/media to validating whole book files against API-driven accessibility validation services such as those being developed by the DAISY consortium.
Longleaf Services proposes that component types be changeable. Currently, it’s possible to change the order of components within each type, but it is not possible to change the component type without deleting a file and reloading it. For example, Introductions are often moved from the main text into the front matter, and abbreviations lists are moved from front matter to the back matter. Being able to use the drag-and-drop function would be more efficient.
Longleaf Services proposes that author name(s), team member names and roles, author name, and current status be visible for each project, and that the page be sortable.
Currently only the title of a project is visible, and projects are listed alphabetically. Team members tend to think of projects by author, not title, so being able to see the author will be helpful. Being able to see the other team members for each project, and what stage the project is in, will help in managing the work. Finally, as the number of projects increases, it’ll be useful to be able to sort out those that are complete from those still in progress. Being able to sort on other attributes, such as series or imprint for example, will also be helpful.
In the interest of conserving space, a user could click on the project title and the list of team members could appear, as it does when one clicks on “Team Manager” on the individual page for each project.
Longleaf Services proposes the caption text box be enlarged. Currently only a limited amount of the caption text is visible; a larger text box would make reviewing/editing the text easier. If there is a total character count limit, it would be helpful to provide the number of characters remaining.
Additionally, perhaps we could encourage accessibility/alt-friendly caption or descriptive entry? Maybe above the text box there could be a suggestion such as, “Consider providing a caption that is accessibility/alt-text friendly.”
punctum books proposed the option to export only parts of a book.
Currently, only an entire book can be exported through paged.js. It would be great if you could select on or more chapters for export, which again would be very useful for edited collections.
punctum books proposes an additional special character: a discretionary hyphen.
Foreign names such as
Nietzsche are often broken off erroneously by automatic hyphenation, for example
Niet-zsche. A discretionary hyphen is an invisible character that shows paged.js where to properly hyphenate a word or name.
punctum books proposes inline semantic markup in Wax.
Currently, there is an asymmetry between paragraph styles, which have semantic values (Title, etc.), and character styles, which have typographical values (italic). Especially with an eye on future export to InDesign formats, it’s important that italics for emphasis and italics for book title, for example, are separated.
At the same time, authors are usually not familiar with this type markup and it might cause confusion. I’m not entirely sure how to solve this practicality.
punctum proposes a language control feature.
I guess this is a big one, and not an enormous priority for us, but something that needs to exist in the future because we often work with multilingual books. There needs to be a way to signal that an entire chapter of part of a chapter is written in a certain language in order to properly control hyphenation (upon export) and interpunction, such as the type of quote marks (curly, fishhook), non-breaking spaces before colons/semicolons (in French etc.), writing direction (Arabic/Hebrew), etc.
punctum books proposes a features that allows you to “tag what you want” in Wax.
This proposal is in line with (and expansion of) our proposal on inline semantic markup. The current number of standard paragraph and character styles is limited, and should remain so. However, there are frequently books that require custom definitions.
I suggest that in Wax you can add a new paragraph or character style by means of (+) button, prompting you to give the style a name (New Fancy Style), from which a slug is generated (
new_fancy_style) that you can then define in CSS, and a simple display format in Wax (italic, bold, indent, etc.). The display format doesn’t have even to be matching or fancy, as long you can then control the tagged words/paragraphs in CSS.
This is a proposal for an indexing tool, written from the perspective of an indexer, not a production editor. It would be great to have some feedback from the production side. I do not know what happens to an index after it is submitted to a press.
Ideally, Editoria should accommodate, or improve on, the two most common professional back of the book indexing methods:
- Writing and editing an index using the final page proofs. This method has multiple approaches, which includes a) marking the page proofs, then entering the headings and page numbers into an editor, and b) displaying the page proofs on a monitor, and entering the headings and page numbers directly into the indexing software/editor, which simplifies many aspects of the editing process and automates all of the formatting specifications, which can vary by publisher and or text.
- Embedded indexing, where an indexer can create an interactive/XML index by marking up/tagging the text during the production process for exporting with the final page proofs. While I’m not as familiar with embedded indexing, I am aware that there is a general sentiment among indexers that they do not produce the quality well-structured analyzed indexes desired for scholarly monographs. However, publishers cite benefits to the workflow. For example, first page proofs will be of the entire book, including a fully set index in page form; overall schedule time should be shorter; they have a fully usable index in whatever form the content is published in, now and in the future. Few indexers are trained in this method. If Editoria could simplify (GUI interface required) the process of compiling and editing a quality index during the production process, rather than as the final task before the book goes to press, it would be adopted widely. I’ve discovered a new commercial effort that claims to do this, but I haven’t used or seen it demonstrated, Index Manager.
METHOD 1, TRADITIONAL INDEXES Most indexes are created by professional freelance indexers (using one of the three highly sophisticated indexing software programs, Sky, Cindex and Macrex), who are hired by the authors. Freelancers may submit the final index file to the author or the production editor. Indexes are generally submitted to the press/author as a double-spaced single column file, with the requisite detailed formatting Feature_proposal-indexing_tool.docxSample_Index.RTF requirements. I do not know what production editors do with the index once it is received from the indexer, or how that process could be simplified for them.
- Editoria should allow for an indexer to write and edit an index within Editoria using the final page proofs AND allow an indexer, or team manager, to submit into Editoria an RTF file of an index generated from the final page proofs
METHOD 2, EMBEDDED/XML INDEXES Any automated XML indexing tool should be able to handle these very basic and common indexing practices:
- To create multiple index styles automatically – indented and run-on (examples can be supplied if necessary).
- To create main headings and subheadings, including words and phrases that do not appear in the text.
- To alphabetize all headings and subheadings and choose between letter-by-letter and word-by-word alphabetizing order.
- To designate stop/ignored words in alphabetizing.
- To create and auto-format cross reference style and placement, See and See also.
- To indicate how page ranges should be handled (e.g., simple, aggressive, aggressive 2, Chicago, Chicago 2; examples of effects can be supplied if necessary).
- To indicate the character to use between page numbers, hyphen or en dash.
- Punctuation placement (commas, semicolons, colons) should be automated.
- To indicate how many columns the index will be.
- To generate an introductory note to describe special features of the index.
As mentioned above these are basic practices. Fine tuning some of the more complex aspects of constructing and editing an index would be an ongoing effort. They concern what occurs after completing the rough index, when an indexer edits it for structure, clarity and consistency, formats it to specifications, and proofreads it. Anything to simplify the XML-index editing and output process in Editoria would be an improvement over the current complex and time-consuming options that indexers currently have for XML-indexing that is not compatible with their indexing software programs.
I’ve attached a Word file of the proposal and a sample index, submitted to Cambridge.
Longleaf Services proposes a function that allows team members to be notified when the status of a project changes—For example, “File _____ is available for editing”
I’d think an email alert would be best, as it doesn’t require the person to be logged into Editoria to see the notification: An author, for example, wouldn’t necessarily bother logging in unless they knew the file was ready for them.
If feasible, development-wise, it would be useful to let the Production Editor decide who (that is, which team member) should get the notifications for a project. There are instances in which one user (generally the PE) performs multiple functions, such as also being the copyeditor, and wouldn’t want/need the notification that a file is ready to edit.
Attaching our sketch and some notes from the community meeting:
Completed / abandoned books need a long-term archiving solution, and users probably won’t want these titles cluttering up their Books Dashboard, so we propose a new ‘archive’ option on the Books Dashboard that would spawn a modal with options for where to send the archive and what to do with the dashboard entry. These options could be configured by an admin to connect to various preservation solutions (e.g. LOCKSS, Portico, FTP).
There was also some debate regarding whether this functionality made more sense at the Book Dashboard level, or at the final export step; though export is something that – at least while it’s functioning as a preview, which it is now – is used repeatedly, while archiving likely happens once.
… of course there might be cases where an archived book comes back to life, so there would need to be a way to enabled that, and / or perhaps a clone / fork feature (e.g. for a future edition).
Longleaf Services proposes that the option to print be available.
Our pilot project requires that a print version of the final file be available to participating authors/presses to satisfy tenure committees, reviewers, and awards committees that don’t yet accept digital versions. Would it be possible to provide the option to download a project’s pdf version, next to the option to download the epub?
Taken in the Atlas Mountains by Karien. I added some text also to yesterday’s post about the trip.
Jenny, Karien and I took a day to go explore a valley in the Atlas Mountains just outside Marrakesh. It was an awesome day. Started on the rooftop of the apartment I rented..
Then Jenny, Karien and I met in the Medina square (Jemaa el-Fnaa) for breakfast and hit the road… Jenny had organised a local guide for the trip.
First stop was to look at the mountains and we stopped at a Berber co-op to look at locally made crafts. I bought a tagine and hooded cloak (Djellaba). Will take pics and post later.
Next to the craft shop was a small building where they put metal bands around the outside of tagines. They let me snoop around as they wielded the bands to the tagine.
Then we drove for a bit and stopped at the base of the Atlas Mountains. There were a lot of cafes along the roiver bank and we stopped here for some food and just to hang out. Jenny went for a walk while Karien and I hung out.
We then drove back down the valley, taking a few photos of other cafes, as well as some villages, as we went.
Then the guide took us to a Berber family home for tea… they were lovely people and gave us permission to take some photos of their house. Inside they had a cow, a heap of tagines and the coal cooking pots for tagine, a millstone for making flour, a bread oven … it was super fascinating. Our hosts were wonderful and the team and assorted nuts and biscuits were delicious.
We returned to the square at night and had dinner together before going our separate ways… each off for our own Moroccan adventures over the next days…. it was a perfect day.
This last week I have been in Morocco with a Shuttleworth Gathering. Its been a great week. Amazing venue, great conversations, date palms, terrapins, amazing food… last night we also went into the Medina and wandered around the Souks (markets)… amazing…