Windows 10 15.0.3 broke Book TOC when exporting to EPUB; works in 15.0.2

Not only did 15.0.3 eliminate Book > Export to EPUB option of EPUB Version 2.0.1, it changed the Table of Contents to include duplicate entries linking to every PAGE within a chapter. The Book.epub file had a separate .xhtml file for every page in the book, rather than one .xhtml file per chapter and one TOC entry per chapter. This makes the Table of Contents useless.

Reverting InDesign back to 15.0.2 fixes the problem.

Here are the parameters I used to export the EPUB:
Book Menu :
Export Book to EPUB (Reflowable)
General
Version : EPUB 2.0.1
Cover : Rasterize First Page(change later)
Navigation TOC : Multi Level(TOC Style)
TOC Style : Table of Contents Style
Content : Based on Page Layout
Text
Option : NOT Remove Forced Line Breaks
Footnotes : Placement: End of the section(Endnote)
Lists :
Bullets : Map to Unordered Lists
Numbers : Convert to Text
Object
DO Preserve Appearance from Layout(for Graphic / Media objects)
NOT Use existing Image for Graphic Objects
CSS Size : Relative to Text Flow
Layout : Align Center
Space Before : 0 Pixels
Space After : 0 Pixels
NOT Insert Page Break
NOT Ignore Object Export Settings
Conversion Settings
Format : Automatic
Resolution : 300 PPI
JPEG Format : Baseline
JPEG Quality : Maximum
HTML & CSS
Include classes in HTML
Generate CSS
Preserve Local Overrides
Include Embeddable Fonts

JavaScript

Metadata
Identifier : urn:uuid:5365cc97-ed5a-4e7c-b325-715c0649c355

Viewing Apps
Kindle Previewer 3.39.0

I have .indd and .epub files from both 15.0.3 and 15.0.2, but I'd rather not publish them to the world. I'd rather you contact me and I'll e-mail you a link to them.

Using CC2019 on a Mac running High Sierra

Steps to reproduce:
1) Create a document with a few hyperlinks in it.
2) Whilst this document is open, open a 2nd document, and copy/paste the links from one document to the other.
3) Save both and close.
4) Trash source document

Expected result: hyper links should work in Target document as expected.

Actual result: hyperlinks all appear broken in document. Whilst an exported PDF appears to still work, ID reports all those links as broken.

Other details:
If you retrieve the source document from the trash, it the links in the target document suddenly start working again, meaning your not actually pasting the hyperlink, but theres some sort of link that exists between the source and target document.

Saving target file as a new file, saving as idml, has no effect – those links are still tied to the source document.

This in an absolute tragedy if you are working on large documents with lots of links, and needs fixing ASAP

I'm using Indesign 15.0 on MacBook Pro (Retina, Mid 2012) running Mojave version 10.14.6

I'm experiencing a bug with the Source Serif Pro font , which I use extensively in a particular project.

I open an existing document, and the text in Source Serif Pro looks as you'd expect it to. When I start to edit the text however, it all jumps down as if the baseline settings of the text frame has been changed (although checking in the settings confirms they haven't been).

Copying and pasting the frame, or the text into a new frame, doesn't help.

It only happens with Source Serif Pro (all weights) - if I change the font, even to other Adobe Fonts it doesn't happen. It also happens in new documents.

It may be worth mentioning that a colleague works on the same Indesign files on a PC (we share the files via Dropbox) but he doesn't experience the issue.

We both share another related bug with Source Serif Pro in that quotation marks just display as 'straight' even though 'use typographer's quotes' is turned on in preferences. This can't be fixed through the Glyphs panel either.

My feeling is it's something to do with this particular font being used a lot over 2 different platforms.

Thanks

When importing a Word document that contains some indented paragraphs, the left indent being set to 5mm in Word (for example), once placed in InDesign, these 5mm indents typically show as 4.992mm. This would not neccesarily be a problem except that Find/Change in InDesign will not recognise an indent to 3 decimal places and therefore this cannot be located easily and fixed. This is proving to be a big problem in my workflow as I cannot automate the process of re-styling these paragraphs using InDesign Paragraph Styles with Find/Change. This bug occurs whatever measurement system is used, i.e. mm, inches, pts etc. Version of InDesign used: 14.0.3 although the same problem exists back to CS6 at least.

The inclusion of ~F in a character class invalidates grep expressions in endnotes.

InDesign version: 14.0.2.324 (with the GREP fix installed)

Steps to reproduce:

1. Open the attached document. It contains a single page with text and an endnote.
2. In the GREP tab of the Find/What window, enter the following GREP expression:

\d[^.,;~F]+

And target the document. The expression matches from a digit up to the next period, comma, semicolon, or footnote marker.

Expected result: The expression should match some text in the main text and in the endnote.
Actual Result: The expression does not match anything in the endnote.

To show that it's ~F that's the problem, use this expression:

\d[^.,;]+

It matches in the main text and in the footnote, as expected.

I'd like to report a bug. Please follow the scenario below:

1. In a single column with lots of text in it, make two columns for a fragment of text

2. In text within the two-column setup, make a footnote. Add several lines of text to the footnote

3. Turn on the "Span Footnotes Across Columns" feature so that footnote ends up in the same group with the footnotes at the bottom of the page rather than below the two-column fragment

4. Expected behaviour: normal editing can be performed after these manipulations

5. Observed behaviour: any text editing after turning on the "Span Footnotes Across Columns" feature becomes lethargic and near impossible. Turning this option off immediately solves the speed issues.

Please log a bug to fix this behaviour.

InDesign 14.0.2 and Acrobat Continuous 2019.10.20099

This issue is about the behavior and appearance of interactive check boxes in documents that have been exported to Interactive PDFs.

There is a difference in the way that check boxes created in InDesign behave and appear versus those created in Acrobat Pro. The Acrobat Pro Forms preferences are involved in this difference.

When, in Acrobat Pro Forms Preferences, under Highlight Color, the “Show border hover color for fields” option is selected, check boxes created in InDesign behave and appear in the following manner.

When a check box is made active, it first appears the same as the check box that was created in InDesign. When you tab to or select another check box, or when you save the selection in the PDF, the appearance of the check box reverts to a default generic check mark.

When, in Acrobat Pro Forms Preferences, under Highlight Color, the “Show border hover color for fields” option is not selected, check boxes created in InDesign behave and appear in the following manner.

When a check box is made active, it first appears the same as the check box that was created in InDesign and remains as such.

This degrades the purpose of using the highlighted fields, which is to call attention to fields that need to be filled.

When the check boxes are created in Acrobat, it makes no difference in appearance or behavior if the “Show border hover color for fields” is selected or not. They always appear as the checkbox style you have chosen to use. They do not revert to a generic check mark.

This is the way that custom check boxes created in InDesign should behave. Thus, they would allow the use of a highlighted field without the appearance of the “selected” custom graphic changing to an unwanted generic graphic.

Please refer to the InDesign Forums message at this link for examples:

https://forums.adobe.com/message/11063952#11063952

I'm experiencing a bug where Nested Line Styles are interfering with Grep Styles.

To reproduce:
1. Create a Character Style "Small Caps" that only applies OpenType All Small Caps.
2. Create a Character Style "No Break" that only applies the No Break rule.
3. Create a Paragraph Style "Test":
    a. In Nested Styles, add Small Caps for 1 line
    b. In Grep Styles, add:
        i. Small Caps: ([\u\d&@#\$%/]{2,}(?!\l{2,}))|([\d&@#$%]+)|(I'D)
        ii. No Break: (?<=.{55}).{15}$
4. Fill with placeholder text, and add a string of capital letters (something that matched the Small Caps grep) somewhere in the middle

You'll notice that the line style and grep small caps work, but the No Break style isn't being applied. Switch the order of the grep styles (No Break first) and now it's the opposite—No Break works but not Small Caps.

Now, remove the Line Style, and suddenly both grep styles work.

Refer to the attached screen shot. I can also provide a sample .indd file with the styles prepared. I've used styles set up like this for a while without problems, so this may be related to a recent InDesign update.

I am using InDesign CC 2019 14.01 x64.

Once a stroke weight has been added, if you then change the stroke weight back to zero, then when you export to pdf the pdf will have a stroke weight added to the text, even though the indesign document looks correct. It may not have the original amount of weight that was added, but it will definitely have what looks to be around a .2 weight added.

However, if you were to start a new document, then add stroke weight, then click edit - undo stroke weight, then it would export to pdf just fine. However if you saved the document with the stroke weight added, and then re-opened and changed the weight to zero, then when you export to pdf it will have a stroke weight still added (around .2, same as above).

So once you have saved a document with the stroke weight added, then no matter what you do the document will not print without the added weight.

If ANYBODY has any idea how to fix this then PLEASE let me know :) I was on chat for 4 hours but no luck. I'm really not trying to redo this 600 page book.