Underline within a table

How can I add an underline within the cell of a table. When the underline tag is entered the underline is produced through the text. I need to be able to underline single words or phrases within a table cell. Below is an example of what is happening.

We are currently setting up a project that requires the same format - underline the contents of fields that are populating a table.

I am having the same issue... the best I can do is set top/bottom margin tags to '0'. However, instead of the underline being underneath the word it is appearing at the top of the word.

What are we missing?

Thank you, Dan. That should get us what we need.

However, it would be nice if the underline could be 'pushed' away slightly from the bottom of the text and also control the thickness. Other than creating and placing an inline graphic (for the underline) with adjusted leading and variable width using some sort of CopyfitLine function is there any other way to achieve this.

Dan,

I have a followup question the refers to the legacy line leading feature. Is there a way to turn that on for only a specific text box in a template and not globally? Or better yet to be able to turn on and off an over-ride paragraph tag for a section?

I have a postcard project where the customer (a real estate agency) can enter a description of the home on the postcard and that text is supposed to wrap around the uploaded picture of the house that is also on the front of the card. The first letter of that description is supposed to be a sort of a "drop cap" effect but just in the fact that the first letter is a different font and size than the rest of the paragraph.

I am able to work out the programming for the first character being different using paragraph and font tags and the sentence looks fine when displayed by itself in a text box that does not have text-wrapping affecting it. But when the text wrapping is applied the one sentence that is to be "wrapped" when it passes below the level of the picture has a much larger extra leading gap than the rest of the paragraph. This occurs when legacy line leading is turned off. If I turn on the legacy line leading feature the part of the paragraph that "wraps around" the picture now works perfectly, but there now is that same huge gap under the first line at the top of the paragraph where the different character is. In this instance "I'm damned if I do and damned if I don't".

I've tried setting different tags for leading in the paragraph to try and force the issue to correct itself, but the global legacy setting seems to override all paragraph tags in regards to line leading. However "leadafter" and "leadbefore" tags seem to work correctly whether legacy is turned off or on.

Any ideas?

.

Turning on use legacy line leading fixes the underline but changes all leading values in the document. As David already asked, is there a way to turn legacy line leading on or off for that flow only. Does leagacy line leading mean the leading newsize tags are dissabled?

I have had the same problems with the text wrap feature. There is always some extra line space added under the wrapped text or graphic box. I have had to create two independent text boxes and set them to text flow so that I can have control over the spacing. This only works if you don't have some kind of variable leading value applied to that text flow. It would be nice if the wrap feature was consistent or at least predictable.

Sorry for the delay. I was looking into ways to answer these questions with something other than No, but for the most part I wasn't too successful.

However, it would be nice if the underline could be 'pushed' away slightly from the bottom of the text and also control the thickness. Other than creating and placing an inline graphic (for the underline) with adjusted leading and variable width using some sort of CopyfitLine function is there any other way to achieve this.

Unfortunately, No. In the current version of FusionPro, underline position, style, and thickness cannot be modified. You can do some tricks with table cell borders and text measurement, but that won't work if you're already in a table (nested tables are not supported).

I have a followup question the refers to the legacy line leading feature. Is there a way to turn that on for only a specific text box in a template and not globally? Or better yet to be able to turn on and off an over-ride paragraph tag for a section?

Again, No. That's why it's a "Global" setting. (Although I should note that as of FusionPro 6.0, the superscript, subscript, and small caps ratios and offsets in that Global Paragraph Settings dialog can be overridden at an individual paragraph level; however, the word spacing and legacy leading settings are still truly "global" to the entire job.)

I have a postcard project where the customer (a real estate agency) can enter a description of the home on the postcard and that text is supposed to wrap around the uploaded picture of the house that is also on the front of the card. The first letter of that description is supposed to be a sort of a "drop cap" effect but just in the fact that the first letter is a different font and size than the rest of the paragraph.

 

I am able to work out the programming for the first character being different using paragraph and font tags and the sentence looks fine when displayed by itself in a text box that does not have text-wrapping affecting it. But when the text wrapping is applied the one sentence that is to be "wrapped" when it passes below the level of the picture has a much larger extra leading gap than the rest of the paragraph. This occurs when legacy line leading is turned off. If I turn on the legacy line leading feature the part of the paragraph that "wraps around" the picture now works perfectly, but there now is that same huge gap under the first line at the top of the paragraph where the different character is. In this instance "I'm damned if I do and damned if I don't".

 

I've tried setting different tags for leading in the paragraph to try and force the issue to correct itself, but the global legacy setting seems to override all paragraph tags in regards to line leading. However "leadafter" and "leadbefore" tags seem to work correctly whether legacy is turned off or on.

 

Any ideas?

.

Well, first off, it's better to start a separate thread for a separate issue, even though these issues are somewhat related. Second, a picture, or an attachment of a template which demonstrates the issue, is worth a thousand words. If I could see the job, then I (or someone else here on the User Forum) might be able to offer more concrete suggestions.

Turning on use legacy line leading fixes the underline but changes all leading values in the document.

Yes, as I said, this is a global setting. Technically, it doesn't really change the "leading values" per se, it just changes the way they are interpreted, and the way that the first line in a text frame is set, based on the actual glyphs of the font used. It also changes the way that "auto-leading" works when the point size changes. A full explanation of this is, well, longer than I have time to write at the moment.

For the most part, the "new" leading produces output that's more "correct," that is, more in line with what other typesetting engines produce, than "legacy" leading did. However, there are a few specific cases where the new leading algorithms do not produce the desired results, which is why we left the legacy algorithms in place as an option.

For the vast majority of jobs, you won't notice any difference between the two leading modes at all, and in the few cases where you do, one setting or the other is usually sufficient for the whole job. That said, obviously there are some jobs like the ones in this thread where a lot of different, sophisticated things are going on, which need a bit of both the old and the new modes, or possibly a change to the behavior of one of them.

But making changes is problematic as well. We tend to be very conservative about changes to the basic composition algorithms, because the worst thing we can do is break jobs that have already been set up to create output in a very particular way that a customer wants. Subtle changes are particularly troublesome, as they might not get noticed before things are printed. We have a very comprehensive regression suite which tests thousands of composition settings and combinations thereof, and we run every new release against it to make sure nothing in the output has changed. Very rarely, we accept a new change as being more optimal and "re-baseline" the regression suite, but for the most part, we strive for consistency in output, even if that means sometimes keeping things that are not as optimal as they could be. My point here is that, unless we hear from customers about specific issues, ideally including either sample jobs or very precise steps to reproduce them, we're probably not going to change any of the fundamental composition algorithms.

As David already asked, is there a way to turn legacy line leading on or off for that flow only.

No, see my answer above.

Does leagacy line leading mean the leading newsize tags are dissabled?

Certainly not. However, it causes the tags to work in a different way. Again, if you could post an example (preferably in a new thread) that shows the discrepancy you're seeing, that would be easier than trying to explain it in the abstract.

I have had the same problems with the text wrap feature. There is always some extra line space added under the wrapped text or graphic box. I have had to create two independent text boxes and set them to text flow so that I can have control over the spacing. This only works if you don't have some kind of variable leading value applied to that text flow. It would be nice if the wrap feature was consistent or at least predictable.

Well, I wouldn't say that it's not consistent. Leading and text wrap are complicated things, and while I admit that FusionPro's handling of these concepts may not always be intuitive, or even "correct" (based on often loose definitions of typesetting terms, which themselves are often inconsistent between various typesetting engines), you will get the same output every time you compose the same job with the same settings. But there are a lot of subtleties involved. Again, posting the job, or a snippet that reproduces what you're seeing, would make it a lot easier to understand what's going on.

If we can get our hands on some specific jobs which are not working the way they should, then in addition to looking at them to try to find workarounds, we will be able to enter cases (bugs), which I assure you will be considered for fixes and/or enhancements in future releases, and possibly added to the regression suite for posterity. So please post your jobs! Feel free to go through Support if the job can't be reduced enough to post here, or contains sensitive information which can't be "dummied out" in a minimal example.