Jump to content
You must now use your email address to sign in [click for more info] ×

Drop caps feature suggestion


Recommended Posts

Hi there

I'm experimenting with Publisher to lay out my next indie novel.

It would be handy to have a check-box function added to be able to apply drop-caps to the second character in a paragraph, rather than the first character - as the first paragraph in a fiction-based novel often starts with a speech mark, and in that instance, you want the drop cap applied to the actual character, not the speech mark.

E.g., if a chapter started:

"Don't you look at me like that!" snarled Bob.

You'd want the 'D' to be the drop cap, not the initial speech-mark, "

This feature already exists in Adobe In-Design, but not the open source package, Scribus.

Congrats on your mind-blowing software, by the way.

I just cancelled my subscription to the complete Adobe Suite (the price rises were too much for me as a non-design agency amateur, with no clients to bill to justify the cost), and have been casting around for pro-level replacements for Photoshop, Illustrator and InDesign on the PC, and came across the Affinity range by accident via a youtube video that mentioned them.

Stephen

>>>>>>>>>>>>>><<<<<<<<<<<<
Stephen Hunt
****************
International best-selling author of ...
The Court of the Air (HarperCollins Voyager/Tor)
The Kingdom Beyond the Waves (HarperCollins Voyager/Tor)
The Rise of the Iron Moon (HarperCollins Voyager/Tor)
Secrets of the Fire Sea (HarperCollins Voyager/Tor)
Jack Cloudie (HarperCollins Voyager/Tor)
From the Deep of the Dark (HarperCollins Voyager/Tor)
In Dark Service (Gollancz/Hachette)
Foul Tide's Turning (Gollancz/Hachette)
The Stealers' War (Gollancz/Hachette)
****************
Find all my latest fantasy and SF novels on my web sites at ...
StephenHunt.net (my blog)
SFcrowsnest.info (my magazine)
>>>>>>>>>>>>>><<<<<<<<<<<<
Get social with me at...
facebook.com/steampunkish
facebook.com/SciFi.Fantasy
twitter.com/s_hunt_author
>>>>>>>>>>>>>><<<<<<<<<<<<

 

 

 

Link to comment
Share on other sites

  • 2 weeks later...
On 12/3/2018 at 2:16 PM, Stephen Hunt said:

It would be handy to have a check-box function added to be able to apply drop-caps to the second character in a paragraph, rather than the first character - as the first paragraph in a fiction-based novel often starts with a speech mark, and in that instance, you want the drop cap applied to the actual character, not the speech mark.

This should happen by default. Have you tried it?

We didn't want to use a checkbox because you will often want to make the drop cap part of a text style, and you wouldn't know what the checkbox should be for the style. You'd probably end up with two styles, one for paragraphs beginning with a quote and one for normal paragraphs. As it works now, the drop cap will intelligently adapt to whatever text is in the paragraphs it is applied to.

Link to comment
Share on other sites

22 minutes ago, Dave Harris said:

This should happen by default. Have you tried it?

We didn't want to use a checkbox because you will often want to make the drop cap part of a text style, and you wouldn't know what the checkbox should be for the style. You'd probably end up with two styles, one for paragraphs beginning with a quote and one for normal paragraphs. As it works now, the drop cap will intelligently adapt to whatever text is in the paragraphs it is applied to.

What would be nice in this situation when the quote or other marks are not desired to be scaled along with the DC character, is by adding an Max Character Count in the Initial Words section. And the logic being if there is not what is found in the Entry field at the p.style beginning that this behavior is skipped.

BTW, hanging punctuation is disabled if I use a c.style to scale down a quote mark to fit the p.style size in an attempt to achieve this.

Link to comment
Share on other sites

  • 6 months later...

I have been looking for how to control how many characters are included in the drop cap, and there doesn't seem to be a way, so I would like to jump on Stephen Hunt's suggestion for more control of drop caps.

I do somewhat like the idea for the drop cap to "intelligently adapt" as Dave mentioned above. I really do appreciate the goal to not have more than one style (eg. Drop cap - 1, Drop cap - 2) just because I need to vary the character count based on content. However, the current implementation is limiting. Here are a couple examples:

1) With numbers. I am currently laying out out a French version of the Bible (I'm still using InDesign for that project), and I need each chapter number to use drop caps. For example:

1183457721_ScreenShot2019-07-03at1_34_40PM.thumb.png.d3dc1843a797ac7cbff831f3c810d051.png

 

In Affinity Publisher, only the single digit chapters would work. I think I would have to use something like pinning to work around this limitation, but as there are 1,189 chapters in the Bible, that is not a solution I am willing to use, besides the downside of moving semantic information (chapter number) outside of the text flow.

2) It is our preferred style to include the apostrophes following prefixed articles, pronouns, and propositions as part of the drop caps. For example:

237551052_ScreenShot2019-07-03at1_49_55PM.png.79bdde53ee87f0c76a977e5327a6a61d.png

 

The current "intelligent adaptation" is not intelligent enough for these scenarios. There may always be scenarios where an automatic solution, no matter how robust, would be more of a limit than a help.

For a start, I suggest adding the field for number of characters to be included in drop cap, and include "auto" as an option, which would refer to the current behavior.

To take it further, give us some control to define what happens automatically. Perhaps a set of checkboxes for different scenarios. Or regex matching—that would be the bee's knees.

 

Link to comment
Share on other sites

Make a Character Style and use it as the Initial Words style to use. Set the words to one.

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

  • 1 month later...
On 7/3/2019 at 12:04 PM, garrettm30 said:

I have been looking for how to control how many characters are included in the drop cap, and there doesn't seem to be a way, so I would like to jump on Stephen Hunt's suggestion for more control of drop caps.

I do somewhat like the idea for the drop cap to "intelligently adapt" as Dave mentioned above. I really do appreciate the goal to not have more than one style (eg. Drop cap - 1, Drop cap - 2) just because I need to vary the character count based on content. However, the current implementation is limiting. Here are a couple examples:

1) With numbers. I am currently laying out out a French version of the Bible (I'm still using InDesign for that project), and I need each chapter number to use drop caps. For example:

1183457721_ScreenShot2019-07-03at1_34_40PM.thumb.png.d3dc1843a797ac7cbff831f3c810d051.png

 

In Affinity Publisher, only the single digit chapters would work. I think I would have to use something like pinning to work around this limitation, but as there are 1,189 chapters in the Bible, that is not a solution I am willing to use, besides the downside of moving semantic information (chapter number) outside of the text flow.

2) It is our preferred style to include the apostrophes following prefixed articles, pronouns, and propositions as part of the drop caps. For example:

237551052_ScreenShot2019-07-03at1_49_55PM.png.79bdde53ee87f0c76a977e5327a6a61d.png

 

The current "intelligent adaptation" is not intelligent enough for these scenarios. There may always be scenarios where an automatic solution, no matter how robust, would be more of a limit than a help.

For a start, I suggest adding the field for number of characters to be included in drop cap, and include "auto" as an option, which would refer to the current behavior.

To take it further, give us some control to define what happens automatically. Perhaps a set of checkboxes for different scenarios. Or regex matching—that would be the bee's knees.

 

I'm looking for a way that three numeric digits (i.e. "150") to be included in the Drop Cap. Can only seem to get the first digit, even with Initial Word set.

Link to comment
Share on other sites

On 8/9/2019 at 7:01 PM, MJBFI said:

I'm looking for a way that three numeric digits (i.e. "150") to be included in the Drop Cap. Can only seem to get the first digit, even with Initial Word set.

Perhaps someone here can think of a clever workaround, but I think currently Publisher is not able to do what you are asking. That is why I think there needs to be some way to give the user control of what gets included in the drop cap.

Link to comment
Share on other sites

On 8/10/2019 at 2:01 AM, MJBFI said:

I'm looking for a way that three numeric digits (i.e. "150") to be included in the Drop Cap. Can only seem to get the first digit, even with Initial Word set.

Use the A (artistic text tool) and type in 1. Use the Drop cap on the 1. Artisitc tool 5 and drop cap and artictic tool 0 Drop cap, all same size. With alignment you can align the way you like. All 3 digits same size. You can group them.

 

Link to comment
Share on other sites

On 7/3/2019 at 9:04 PM, garrettm30 said:

[...]

1) With numbers. I am currently laying out out a French version of the Bible [...]

+1

I would only comment on your footnote position (2 in your example). An advanced rule is to always append footnote call ("l'appel de note", the "2") to characters, never to punctuation.  And I would personnaly add a small fixed width space before.

I aggre with all the examples of this thread (number at the begining of paragraphs, quotes -- but I would use the curly ones in French at the beginning in drop caps for graphical/aesthetical effect, the other ones are uggly or dismissed usually, but that's a readability problem and that' s why we tend to keep them today--, etc.

Link to comment
Share on other sites

On 8/10/2019 at 1:01 AM, MJBFI said:

I'm looking for a way that three numeric digits (i.e. "150") to be included in the Drop Cap. Can only seem to get the first digit, even with Initial Word set.

The Bible is the most demanding book to typeset. It exposes deficiencies/lack of features of any publishing software used.

I'm afraid, Affinity Publisher is not there yet to meet that challenge. But in time I hope it will.

Quite a long time ago I suggested a feature that would deal with so called "sense lines". I don't want to go into the detail now of why it's useful in Liturgical Texts and the Bible by extension.

If added it would be the only Typesetting Application that would have it. 

 

2017 27” iMac 4.2 GHz Quad-Core Intel Core i7 • Radeon Pr 580 8GB • 64GB • Ventura 13.6.4.

iPad Pro (10.5-inch) • 256GB • Version 16.4

Link to comment
Share on other sites

13 minutes ago, Seneca said:

The Bible is the most demanding book to typeset. It exposes deficiencies/lack of features of any publishing software used.

I'm afraid, Affinity Publisher is not there yet to meet that challenge. But in time I hope it will.

 

If you don't mind this tangent, I would like to add my comments to your statement that "the Bible is the most demanding book to typeset." Most of our other projects I have been attempting to do in Affinity Publisher with various workarounds when needed, but Publisher is not ready for the Bible project for these reasons in my view:

  1. Drop caps limitations, as in the current thread
  2. Lack of text variables based on style - for creating automatic running headers
  3. No multiline composer
  4. Lack of "book" feature - that is, being able to have a long publication split into several separate but coordinated documents

We would have to add lack of footnotes as a limitation, but fortunately we are not using footnotes in this edition.

The amount of work necessary to work around these limitations would be enormous on a publication this large (just nearly 1500 pages).

Link to comment
Share on other sites

9 hours ago, garrettm30 said:

Publisher is not ready for the Bible project for these reasons in my view ...

Yes, I agree that we need all the features.

I would simply add just one more to the mix – automation/scripting. This feature is crucial in any non trivial job.

But like I said earlier, Publisher is very fresh and these and other features will be added later. Hopefully, in not too distant future.

2017 27” iMac 4.2 GHz Quad-Core Intel Core i7 • Radeon Pr 580 8GB • 64GB • Ventura 13.6.4.

iPad Pro (10.5-inch) • 256GB • Version 16.4

Link to comment
Share on other sites

9 hours ago, garrettm30 said:

If you don't mind this tangent, I would like to add my comments to your statement that "the Bible is the most demanding book to typeset." Most of our other projects I have been attempting to do in Affinity Publisher with various workarounds when needed, but Publisher is not ready for the Bible project for these reasons in my view:

  1. Drop caps limitations, as in the current thread
  2. Lack of text variables based on style - for creating automatic running headers
  3. No multiline composer
  4. Lack of "book" feature - that is, being able to have a long publication split into several separate but coordinated documents

I do agree with #s 1&2.

#3, I never use it in ID.

#4, if the book files are per chapter, or books of the Bible in this case, are in separate files, the page numbering can be other wise be controlled, just nor synchronized via a book feature. 

Link to comment
Share on other sites

18 hours ago, MikeW said:
On 8/12/2019 at 9:31 AM, garrettm30 said:
  1. Drop caps limitations, as in the current thread
  2. Lack of text variables based on style - for creating automatic running headers
  3. No multiline composer
  4. Lack of "book" feature - that is, being able to have a long publication split into several separate but coordinated documents

I do agree with #s 1&2.

#3, I never use it in ID.

You never use multiline composer (called "Adobe Paragraph Composer" in Indesign)? That surprises me, as it is the default composer. So that means you are making a conscious decision to select "Adobe Single-line Composer" in your layouts. If you don't mind sharing, I feel I might have an opportunity to learn something I hadn't thought of before if you would tell why you prefer the single-line composer. I have always wondered why leave it as an option.

For my part, this is a sample screenshot in InDesign from the Bible project I have been referring to, except this time I have set up side-by-side copies of the same column, once with the "Adobe Paragraph Composer" (what I referred to in my list above as multiline composer) and the more basic "Adobe Single-line Composer," which is analogous to the method Affinity Publisher is using. Other than the composer chosen, there is no other change to the two copies of text.

1545212996_ScreenShot2019-08-13at1_37_43PM.thumb.png.3e2ac693f04c22c3267f5a6b0b5d46d5.png

The multiline (left) has a much more consistent spacing across the whole paragraph, while the single-line (right) has less consistent spacing and some really horrible gaps that would have to be dealt with manually (and then dealt with all over again at the slightest text reflow caused by editing or style change). It is this inconsistent spacing that I have been dealing with in Publisher, and truly, the lack of a multiline composer is my own greatest missed feature when using Publisher. Literally everything we do has justified body text, and almost always with multiple columns, therefore, more narrow columns where the difference is more noticeable. I have been doing it manually in our shorter publications, although I never like the result as well, and it does take me a not inconsiderable amount of extra time.

 

Link to comment
Share on other sites

9 hours ago, garrettm30 said:

You never use multiline composer (called "Adobe Paragraph Composer" in Indesign)? That surprises me, as it is the default composer. So that means you are making a conscious decision to select "Adobe Single-line Composer" in your layouts...

I'll take back the never word. I do use it for certain books I layout (rather, re-layout). I do some work for one imprint that is the reformat of hardbacks to trade-size paperbacks. There isn't much money in them and the paragraph composer is quicker.

So yes, my default style was changed to the single-line composer.

9 hours ago, garrettm30 said:

... If you don't mind sharing, I feel I might have an opportunity to learn something I hadn't thought of before if you would tell why you prefer the single-line composer. I have always wondered why leave it as an option.

I don't mind...but I doubt there is anything below that is new to you.

In general, similar results can be made using the single-line composer. The same results? Nah. Similar. Worse? Better? Both in often different text runs, sometimes the same text run. The decisions either composer makes can range from poor to acceptable to good to great. 

What I do not like about the p.composer is the editing process. The copy-fitting editing, the tracking/kerning part for lengthening/shortening of a given text and having the text recompose above the working selection. It drives me batty. I have never found the p.composer to always make the right decisions over even a small book. That said, the same applies to the s.line composer as regards the way text can break, not break when it could, etc. 

I always make tweaks to the justification settings. What tweaks depend on the layout factors--column width, font, point size, how many hyphens (if any) are allowed and/or allowed in a row, etc.

Anyway, I've attached a PDF for your amusement, OCR'd from the screen shot. I didn't expend much effort. Made using ID CS6. Three columns. Both types of composer and a column from QXP. Not in any particular order. There is at least one line in each I would normally tweak if important to the client. One column has at least one word needing a discretionary hyphen, one has a word I would place a no-break on, etc.

Here's one last thing. Either of us could likely pull examples to demonstrate the efficacy of one composer or the other from here til eternity. I believe in the end, we need to make ourselves happy, proud, with our results--and in that way so will the client.

Best regards, Mike

Untitled-1.pdf

Link to comment
Share on other sites

I do appreciate your explanation. I take it that you are very proficient with the manual adjustments. I really am not. With Publisher I have no other choice but to laboriously go through the text, and in the end, due to my lack of proficiency perhaps, I am less satisfied with the results. I have already had a couple times where I have spent about five minutes on a single paragraph that I could never get quite to my satisfaction, whereas with the paragraph composer I nigh on never have spacing as bad as what I pointed out at the bottom of my sample in the single-line side. I do get it rather often in Publisher.

You have my admiration for your skill and the time you must give to it. But for my current proficiency level in this area, I spend more time and still end up with inferior results as compared to what a multiline composer will do.

And really, thanks again for taking the time for your explanation.

Link to comment
Share on other sites

Thanks...but please don't misunderstand me. Much of my response was academic in that what I used was but one small sample of an entire work of yours. I didn't know how it would layout until I did it and even then I doubt it would layout as well without every item of the layout identical to the original. It just so happened using the font I used, the justification settings I previously used for a similar work, column width, etc., worked out as seen in the PDF. 

And yes, that line at the bottom is poor in the s.composer in your example. However, I also think the same line using the p.composer is too tight, though it is a better compromise if the compound word donne-la-moi wasn't broken at the first hyphen.

Also, I would be remiss if I took anything away from the request! The paragraph composer would be a good addition.

And just for more fun, I've attached a new version with an APub sample with everything else being equal. Note that it would have likely been better if at least the word sacrificateur was in the Hunspell hyphenation file (and some others in the sample used for that matter).

OK. I can hear the teapot calling my name...

Mike

Untitled-1.pdf

Link to comment
Share on other sites

On 8/12/2019 at 8:17 PM, MikeW said:

#4, if the book files are per chapter, or books of the Bible in this case, are in separate files, the page numbering can be other wise be controlled, just nor synchronized via a book feature. 

Agreed - if the book feature is missing, it may be inconvenient for some workflows, but it does not prevent quality work from being accomplished.  #1 + #2 are the biggest showstoppers for a project like this.  #3 is a bit more open to debate but is not clearly necessary (though the work may very well benefit from it if available).

Link to comment
Share on other sites

16 minutes ago, garrettm30 said:

I have enjoyed this interchange with you, and I could keep enjoying it further if I weren't risking hijacking the thread. So instead I'll stop here for the moment and say only that I both like what you said and the apparent spirit in which it was said.

Yes, yes. I do have a (bad) habit of running off on (to me) interesting tangents!

As a mea culpa, I'll leave with a strong endorsement for being able to have more than a single character for a drop cap with the following exaggerated example...

Capture_000138.png.7ae72172a28d1af72d53aac0f02ef889.png

Link to comment
Share on other sites

  • 1 month later...
On 8/12/2019 at 6:56 AM, Seneca said:

The Bible is the most demanding book to typeset. It exposes deficiencies/lack of features of any publishing software used.

I'm afraid, Affinity Publisher is not there yet to meet that challenge. But in time I hope it will.

Quite a long time ago I suggested a feature that would deal with so called "sense lines". I don't want to go into the detail now of why it's useful in Liturgical Texts and the Bible by extension.

If added it would be the only Typesetting Application that would have it. 

 

Thank you Seneca.  I wholeheartedly agree with Bible typesetting demands and the exposure of publishing software deficiencies.  Thankfully, there are manual workarounds with existing Affinity Publisher features that are meeting our needs, not as efficiently as they could be, but at least making it possible.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.