Here's an odd footnote formatting thing: My main Scrivener project insists on creating footnotes during the draft export (rtf or doc) that are Helvetica except for the italic portions of the footnote text, which are Times italic! Leaving aside the TimesNewRoman PSMT issue, in the Scrivener project, all of the footnote text is TimesNewRoman regular and italic on screen. None of it is Helvetica (although it probably was at one time). In the Draft Export dialog, the export font is set to TimesNewRoman.
I've not been able to make any sense out of this or correct it, so I started with a blank project, call it project B, all default preferences. I created one new text document and added a footnote. Exporting Draft from this project B produces the expected Courier body text and Courier footnote text in Word. If I drag a couple of text documents from my main Scriv project into the Binder of project B, the text and footnotes in the whole draft export remain Courier. So far so good.
It changes when I drag a container document from the main project to project B. The container has subdocuments from the main project; it has 2 words of text but no footnotes. So I am including it in the draft just for the two words, which make a subtitle. The subdocuments with their container are now in project B's binder, AFTER the other documents I've created and imported. When I export draft, the container document has "Keep Format" checked, as it did in my main project. No other document has Keep Format checked, including the container's subdocuments. But suddenly, ALL of the footnotes in the export are TNR, even the footnote in the first document of project B.
Turn off Keep Format for this one container document in the export, and all of the footnotes in the draft revert to their Courier default.
Now this weirdness doesn't explain my original problem with footnote formatting, but maybe it's running down the same ditch.
One related note: Applying a para tag in NeoOffice to the oddly formatted footnotes from my main project did not fix the fonts. The footnote acted like a character tag had been assigned to the footnote text by the export, so that just clicking in the footnote and applying the changed para tag did not fix it. I don't know if this is a clue in the mystery, or just my ignorance of setting the footnote style in NeoOffice Writer.
What say you, KB? How is footnote formatting supposed to work in the draft export?
John Robert
iBook G4 with OS 10.4.10
Scrivener 1.055b
Scrivener 1.1 (1.055b) Public Beta - new and updated (AGAIN)
alexwein wrote:
Reminds me of something being 'wicked' or 'wicked bad' which means really good in some parts of New England. You should know that one, or is it just some parts of New Hampshire and Maine that use that expression??
growing up in central New Hampshire it was 'wicked' and 'wicked ex', the 'ex' being short for excellent.
-
alexwein
- Posts: 1063
- Joined: Wed Jul 12, 2006 4:30 pm
- Platform: Mac
- Location: Ashland, Oregon, USA
- Contact:
bgordon wrote:alexwein wrote:'wicked ex', the 'ex' being short for excellent.
Never heard that one! Of course, I was only in NH for five years--the Newmarket/Portsmouth area--so I couldn't have heard everything!
-
OnlineKB
- Site Admin
- Posts: 20827
- Joined: Tue Jun 13, 2006 11:23 pm
- Platform: Mac
- Location: Truro, Cornwall
- Contact:
John - if you are using different fonts or not using an export font, then footnotes font could indeed go slightly crazy, owing to the fact that they are a bit of a hack in that I have had to insert all of this crazy RTF code into the exported RTF stream. The fonts they use will depend on the first font in your RTF table. In other words, is there any Helvetica anywhere in your export? Towards the beginning, perhaps? Footnote fonts should work fine if you have a single font throughout, but they may need adjusting in a word processor if your main text uses different fonts...
Best,
Keith
Best,
Keith
Keith,
What appears to be happening is the following:
My draft export gets Helvetica embedded in the last one or two paragraph markers of each Scrivener project doc, IF I select Single newlines or Double newlines respectively in the Sections panel of the Text Options panel of the Export Draft dialog box.
If I select Scene breaks instead, no Helvetica shows up.
When I search for Helvetica in the rtf export file, Word identifies the font of the last one or two paragraph markers as Helvetica, although the words themselves preceding the marker are Courier or whatever I've defined in the Draft Export dialog.
What can this be?
Thanks,
John Robert
What appears to be happening is the following:
My draft export gets Helvetica embedded in the last one or two paragraph markers of each Scrivener project doc, IF I select Single newlines or Double newlines respectively in the Sections panel of the Text Options panel of the Export Draft dialog box.
If I select Scene breaks instead, no Helvetica shows up.
When I search for Helvetica in the rtf export file, Word identifies the font of the last one or two paragraph markers as Helvetica, although the words themselves preceding the marker are Courier or whatever I've defined in the Draft Export dialog.
What can this be?
Thanks,
John Robert
John Robert wrote
I should have explained that I meant that the last paragraph marker of each Scrivener document exported in the draft shows up in Word and NeoOffice as Helvetica. That is, select the paragraph marker, and Word shows Helvetica, regardless of the font of the text of the paragraph. That happens when I select Single newlines or Double newlines respectively in the Sections panel of the Text Options tab of the Export Draft dialog box.
So somehow, exporting with Single or Double newlines is causing my footnote formatting to go haywire.
Can I see the RTF table with a text editor? I'll try with Text Wrangler.
John Robert
When I search for Helvetica in the rtf export file, Word identifies the font of the last one or two paragraph markers as Helvetica, although the words themselves preceding the marker are Courier or whatever I've defined in the Draft Export dialog.
I should have explained that I meant that the last paragraph marker of each Scrivener document exported in the draft shows up in Word and NeoOffice as Helvetica. That is, select the paragraph marker, and Word shows Helvetica, regardless of the font of the text of the paragraph. That happens when I select Single newlines or Double newlines respectively in the Sections panel of the Text Options tab of the Export Draft dialog box.
So somehow, exporting with Single or Double newlines is causing my footnote formatting to go haywire.
Can I see the RTF table with a text editor? I'll try with Text Wrangler.
John Robert
-
OnlineKB
- Site Admin
- Posts: 20827
- Joined: Tue Jun 13, 2006 11:23 pm
- Platform: Mac
- Location: Truro, Cornwall
- Contact:
Hi John - I'm hoping I've fixed this for the next version. Basically, what was happening was this: Scrivener was inserting an RTF string containing a single or double newline with no attributes in the situation you describe. Under the OS X text system, Helvetica 12 point is default (I hate Helvetica - I wish they had used Times New Roman or something, but that is just a matter of taste), so an RTF string with no attributes will get exported with Helvetica. So, in the next version, those separators are now given the export or default text attributes (depending on export settings) which should hopefully avoid this situation.
Best,
Keith
Best,
Keith
-
OnlineKB
- Site Admin
- Posts: 20827
- Joined: Tue Jun 13, 2006 11:23 pm
- Platform: Mac
- Location: Truro, Cornwall
- Contact:
"In the future at some point" is all I can say. It's nearly there apart from the Help file, but for the past two months I've been saying "in the next couple of weeks", so I don't want to promise anything. Soon, though...
Best,
Keith
Best,
Keith
-
xiamenese
- Posts: 4480
- Joined: Mon Jan 29, 2007 1:32 am
- Platform: Mac
- Location: London or Exeter, UK.
KB wrote:"In the future at some point" is all I can say. It's nearly there apart from the Help file, but for the past two months I've been saying "in the next couple of weeks", so I don't want to promise anything. Soon, though...
Best,
Keith
Keith,
We know you hate writing Help files — Who wouldn't? — and there are much more interesting coding issues you've been dealing with ... quite apart from that novel waiting to be written.
But is there any chance that you might release 1.056B — or whatever — without the Help file before then? After all, for those two months many of us have been running 1.055B without a Help file, and in the full knowledge that it's Beta, and have been basically very happy with it. But in the meantime, you've dealt with a few bugs, like the page-numbering bugs, and I'm sure those to whom that is important would love to be using the de-bugged version that you are currently running, rather than waiting until "some point in the future".
Or is it that releasing 1.056B would give you further cause to procrastinate on the Help file?
We'll all upgrade as soon as the official release comes out ... you needn't fear that.
Mark
The CFBundleGetInfoString and CFBundleShortVersionString properties are missing from your Info.plist, keeping the Finder from showing the version in the Get Info window. Seen on Mac OS X 10.4.10, PPC.
If I do a highlight of text in the edit window, move the cursor into another field like the synopsis section, and do an Undo at that time, the highlighted text is not undone. I have to move the cursor back to the edit window and then do undo for the highlight to work.
Also, I found that if I click on the auto-generate button of the Synopsis section while my text cursor is in the edit field, undo doesn't work for the auto-generate until I put my cursor in the Synopsis section.
Also, I found that if I click on the auto-generate button of the Synopsis section while my text cursor is in the edit field, undo doesn't work for the auto-generate until I put my cursor in the Synopsis section.
The help tag for the toggle split control uses the Windows term "alt" rather than the Mac term "option" for the related modifier key. Although some Mac keyboards do have "alt" on them, not all do.
During the first time running Scrivener (you have to duplicate this by quitting and starting back up), when you choose Export Manuscript, choose the Text Options panel and then the Formatting panel, the check boxes for "Convert em-dashes to double hyphens" and "Convert ellipses to triple periods" shift visually to the left briefly in conjunction with the surrounding group box.
Below the sliders used in the preference panels, there should be some numeric feedback so a user can tell if they hit the same value they were hoping for, possibly to the right in a field or below it with tick marks.