Strange css interpretation

[Isleofgough]

There are two strange interpretations by Flare of css styles that I can't figure out how to fix, except by trial and error.
1. The first issue is lines above and below spacing. In Framemaker, I can set lines above and below that have perfect spacing by setting the advanced option in a paragraph style to "Frame above>single line, Frame below>single line". In Flare if I set border top solid thin and border bottom solid thin and padding 6 px top, 6 px bottom, the text is very close to the top and leaves too much space below. To put the text in the middle of the two lines, I have to set padding to 10 px top, 2 px bottom (see attachments)
2. Drop caps look good in Flare for epub output, but when I open the file in IBooks, the drop cap is way to far down (see attachments).

Is this a user error or another Flare bug?

FlareBorders6_6px.png

FlareBorders.png

FlareDropCapEbook.png

FlareEpubIbooks.jpg

[BedfordWriter]

Lord knows I'm not CSS expert, but I think the first trouble may be related to how the font fits within its defining box. At the least, I'd specify the margins in terms of em rather than px. There are a couple of useful links that I refer to when I'm having trouble with this stuff...
http://webtypography.net/2.2.2
and more importantly:
https://medium.engineering/typography-i ... .8f355bhs0

Hard to know what's happening with the drop caps without seeing the actual CSS, but I note that there are more lines in the paragraph in the second image and that in both cases the drop cap seems to line up with the bottom of the paragraph. That would be my starting point to figure out what's happening. But, epub seems to have special formatting problems from what I've read.

[Isleofgough]

Thank you for your suggestions. It doesn't like Flare likes em settings < 1.0, so I tried point settings, and still have to set the top as five times the bottom to put the font in the middle. The css for the paragraph is:
p.Title
{
text-align: center;
margin-left: 0in;
margin-right: 0in;
margin-bottom: 0pt;
font-family: 'DTL Caspari TOT Medium';
font-weight: normal;
font-style: normal;
font-size: 18pt;
color: #7a4700;
mc-hyphenate: never;
text-indent: 0px;
line-height: 18pt;
text-decoration: none;
margin-top: 2px;
padding-top: 10pt;
padding-bottom: 2pt;
border-top-style: solid;
border-top-width: 1px;
border-top-color: #000000;
border-bottom-style: solid;
border-bottom-width: 1px;
border-bottom-color: #000000;
}

For the drop capital, the css is:

p.FirstParagraphOfChapter:first-letter
{
color: #bed230;
float: left;
margin-bottom: 0;
font-size: 40pt;
margin-left: -2pt;
margin-top: 21pt;
}

p
{
frame-break-before: avoid;
margin-top: 10px;
margin-bottom: 14px;
line-height: 13px;
font-size: 10pt;
font-family: Calibri;
}

p.FirstParagraphOfChapter
{
color: #000000;
}

[BedfordWriter]

Taking it one piece at at time, title border first.

Time to open your browser's style inspector and see what else is going on with that title. I created a .css file with your sample and used it in a simple .htm file. What I got looks like the following:

TitlePadding.png

Seems to me that something else is at play in one of your style sheets. The style inspector should help you track it down.

Not sure what you mean by Flare having trouble with em values less than one. Maybe in the preview, but once the project has been built, you've got a .htm file, a bunch of .css files, and it's entirely up to the browser to paint the result. Flare has nothing to do with it at that point.

Helping solve this is good practice for my .css skills so I can justify the time spent. That said, the drops cap question will have to wait until my afternoon break. Let me know if you work it out.

[Isleofgough]

Thank you for your screen shots. The issue is not just with display in Flare, but it affects targets. You gave an example in HTML where it works as it should with the same distance above and below. In my example, I had targets for epub and pdf, rather than HTML. My experience with Flare is that it does a much better job with web based output than print output, which is not surprising as files are stored as XHTML. In my project, I only have one style sheet, so there is no possibility I am editing the wrong css. The one style sheet does have a few separate paragraph styles for epub and pdf outputs. I set the upper and lower distances for a much larger upper distance and the actual target shows symmetric distances in both the Flare preview and in the generated pdf (see below). However, when I bring the file up in Oxygen XML editor (which would be the web equivalent) it shows the asymetric distances - replicating what you found. So it seems to be an issue specific to print outputs. It does look like the preview puts the lines differently with the two targets (see third attachment and settings). The fractional em setting worked the second time around, so I don't know that the issue was with that.

FlarePdf.jpg

FlareBorderOxygen.jpg

FlareStyles.jpg

[BedfordWriter]

Apologies for missing the detail of target choice. That's certainly relevant.

I still hold that the problem is coming from an as-yet unidentified variable in the mix. I tried to recreate the situation using the MadCap sample project. My steps and results are as follows:
1) I imported your p.Title style into MainStyles.css of the sample project. Used a text editor to copy & paste.
2) Changed the padding to 0.2em top and bottom.
3) Copied that style, replacing the font with Arial. I don't have DTL Caspari and I'm not sure what is being substituted.
4) In the sample project, I used both styles for a topic heading.
5) Created a pdf target with all the defaults in place, then built.

TitlePadding2.png

I magnified the result and added a diagonal blue line to each title so that it would be possible to count pixels. As you can see, my results differ from yours. There's also a small but noticeable difference between the two fonts.

Next I built for epub. Viewing the result using Epub Reader for Firefox, the result is different in unexpected ways. Suddenly the substitute for Caspari is a serif font and Arial got italicized. But, they're still centered. epub is weird.

TitlePadding3.png

Three things that I can think of for you to try:
a) Check that nothing above <p> in the css hierarchy (like <body>) is setting margins & padding.
b) Try copying just your title style and first page to a new, clean project.
c) Try one or two other fonts.

Good luck. I've gone as far as I can with this one.

[NorthEast]

The low position of the drop caps will be because you've set the top margin 21pt - so change that to 0 instead.

Code: Select all

p.FirstParagraphOfChapter:first-letter
{
   ...
   margin-top: 21pt;
}

[Isleofgough]

1. Regarding the lines above and below: thank you for pointing me in the right direction. The issue seems to be very font dependent. I can replicate that setting equal space above and below works with Arial but not with DTL Caspiri. There is a trial and error issue with fonts, it seems.

2. Setting the top margin for drop caps to zero raises the drop cap above baseline. That is a very different look, but not the one I wanted. Drop caps seem to be particularly problematic in ePubs from what I can see on a quick Google search. Different ePub readers interpret them differently. It is a bit difficult, as I need to produce targets for iBooks and Kindle. As it is, there is a need for a fair amount of editing code in Jutoh after export from Flare to fix issues. I've tried Calibre, Sigil, Oxygen, and Jutoh and get the best edits from Jutoh. Unfortunately, this kind of defeats the vision of single sourcing.

[NorthEast]

2. Setting the top margin for drop caps to zero raises the drop cap above baseline. That is a very different look, but not the one I wanted.

I don't quite follow you.

What I was saying is that you already have a top margin set for the drop caps of 21pt, which means it will be pushed down 21pt, which is why the top of the drops cap isn't aligned with the top of the paragraph. So if you set the top margin to 0 instead, then will that not be aligned?

[Isleofgough]

The drop cap is approximately the same style as in the advanced print and web output template (except the font size was changed from 36 to 40 pt). The reason for the space before setting is that a drop cap is traditionally "dropped" two or three lines and the top sits level with the top of the first line characters. One can do the math of font point size and leading, but it is much less common to have the first letter just a big letter sitting well above the surrounding text. As you can see from my initial post, the previews work well with the setting that includes a space before. The pdf output works well (changing 36 to 40 point), but the epub version shifts well beyond the 21 point drop.

[NorthEast]

The reason for the space before setting is that a drop cap is traditionally "dropped" two or three lines and the top sits level with the top of the first line characters.

Yes, I understand that, the top of the drop cap letter should be aligned with the top of the paragraph text.

But you've set the drop cap margin-top to 21pt, so I'd expect the top of the drop cap to be pushed 21pt down, which is probably why it's pushed down two lines (of 10pt text) as shown in your screenshot.

Try setting the margin-top to 0 (zero), and see if the top of the drop cap letter is aligned with the top of the text.


Also, forget what the CSS looks like in Flare's editor, it won't necessarily be the same as the output - especially anything that involves things like floated elements, positioning, or CSS pseudo selectors.

[Isleofgough]

You are correct that removing the space before gives a correct drop cap in iBooks. It is incorrect with every other output, and will display align the baseline and stick up above the rest of the text with every other output. I created a new project using the advanced epub and pdf output and verified that it is incorrect with iBooks when I performed no modification. However, when I changed the font size for drop cap from 36 to 40 and removed the space before for just the ePub verson of the style sheet, it displays correctly. Thank you. FWIW, all other targets will display INCORRECTLY if one changes the space before from 21 pt to 0 pt.