Small caps in running heads - mixed case problem

My running head is set to be small caps, and it picks up mixed-case text from the document. I want the head to be all 'lower case' small caps (or 'upper case', unless that really means ordinary caps) but can see no way to achieve this. Instead I get 'mixed case' small caps, if that makes any sense. If I select the head on the master page and then Type | Change Case, this has no effect on the appearance either on the master or the generated heads. How do I achieve uniform small caps where the source text for the running head is mixed-case? If small .indd attachments were allowed I would have attached one, but it got rejected despite not being llisted as a forbidden type.

A few ways to do this:
a script: http://jsid.blogspot.com/2005/09/script-of-day-changing-case-again.html
or in your paragraph styles use OT small caps (assuming you're using an OT font)
I also set up a keyboard shortcut, to Type > Change Case > lowercase
you could probably do it with GREP too...

Similar Messages

In Acrobat, is there a way to have a form field use small caps in place of lower-case text?

I found java script online that will force a field to be all caps (using it in the format tab > custom format script). But I have not been able to find anything to change the lowercase text to small caps. Anyone know how to do that (or if it just can't be done in Acrobat)?

But if you use a "small CAPs" font, you need to be sure the font is fully embedded in the PDF. If not, it is likely that users will not be able to use your form.

Table and columns in small caps!

Dear All,
My database is 11gR2 and Linux is the OS.
One of my application, whose code I am unable to access, it trying to insert records in Oracle database. The problem is that application is case sensitive and try to find table name and columns in small caps, while it gets upper case from Oracle and give error or invalid identifier.
Is there any option to create table and fields with small letters.
Kindly help.
Regards,
Imran

misterimran wrote:
...The problem is that application is case sensitive and try to find table name and columns in small caps...What application could look for tables/columns in small caps ? As stated above, creating tables/columns enclosed by double quotes might help, but that'd mean the code must use double quotes everywhere...
while it gets upper case from Oracle and give error or invalid identifier. It get as is, please show the error.
Nicolas.

Small caps - is there a way to change size ratio of lower to upper case?

I am using Adobe InDesign CS4 and one problem I've had is that when I select Small Caps on the character styles panel, lower case characters are about 60% the size of upper case characters. I'd like this to be more around 80% in my document.
I don't see a way to do this, so I'm having to avoid using Small Caps and am having to select various portions of each word and set them to different sizes.
Is there a setting I am missing for Small Caps that would save me this trouble? My typeface is Minion so I may also see if there's a variant available that uses well-crafted small caps.
Tim

Dave,
>.. adjust the size of the "lowercase" characters by using a GREP style
Yes ... and no.
It doesn't have to be an extremely complicated GREP style. You mention Unicode ranges, but it's not even necessary. You could try
>[a-z]
to select all lowercase characters, but it leaves out accented ones. Now specifying ranges for these doesn't work very good (to put it mildly), because they do not appear consecutively in the Unicode set.
Fortunately, GREP has a wildcard
>\l
for "lowercase", and this matches
i every
lowercase character (even Greek and Russian ones). It's equal to the POSIX expression
>[[:lower:]]
As this seems to work just the way you want, then why the "No"? The GREP style will be applied to
i all
lowercase characters in the paragraph, not just to the words you wanted.
[Warning: Dirty trick follows. Do Not Copy Unless Forced To.]
Of course you can
i force
the GREP style pick up 'unique' words by making them unique somehow. If you insert an invisible character
i before
and
i after
the words you want to mark -- in the case at hand, the ones you want to small-capitalize --, you can include the invisible characters in the GREP style. For example, by specifying
>~-\l+~-
you can "mark" words by inserting a soft hyphen before and after certain words. (This example also presumes only lowercase characters inbetween.) You don't have to use the soft hyphen, there are a couple more markers you could (ab)use. I think I'll leave it up to your imagination to wonder where it could possibly go wrong.

Problem with Small Caps

I have a problem with small caps when using Times New Roman and Helvetica, but not when using Adobe Garamond Pro, and would like to find out why.
I generate the small caps within InDesign by the "TT" box in the Control Window. Adobe Garamond comes up with beautiful small caps that blend in with the surrounding text. When I do the same with Helvetica, the small caps, especially if they have normal caps amongst them, are quite inelegant looking because of different letter widths.
So I did some experiments with half a dozen other serif and sans-serif fonts and none of them were as elegant as Adobe Garamond Pro. For a sample of what I mean, download:
http://www.mediafire.com/?z5fm0zndmzm
which compares three fonts: Adobe Garmond, Heletica, and Times New Roman.
Unfortunately, I did not pick up this problem until I received my first proof from the printers, and now I will have to change all the Helvetica small caps to normal caps, as I can see no other way of overcoming this inelegancy.
I checked in New Scientist magazine (it uses a serif and sans-serif font throughout, and what I thought I remembered as small caps to begin their stories) to see what they do, but they actually use caps instead of small-caps at the beginning of stories.
Three questions:
Q1: Is the way I generate small caps the correct way?
Q2: Is there something wrong with my Helvetica and Times New Roman fonts?
Q3: Could it be that only Adobe Garamond has an internal, properly designed small caps?
I have checked the attributes of the fonts: Garamond is Open Type Postscript, Helvetica is PostScript Type 1 , and Times New Roman is TrueType.
Any comments most appreciated.

Thanks for the hints. I tried Scott's method and it works with a bit of extra adjustment. The settings I obtained for 12 point Helvetica were:
Horizontal and vertical scaling: 70.5%;
Stroke: 0.1 pt
Tracking: +25 em
Baseline shift: +0.1 pt
The steps to obtain small-caps 12 pt Helvetica are:
Step 1: Type text as normal.
Step 2: Select only the lower-case text you want to convert to small caps. i.e if what is to become small caps already has a capital (such as a place name) do not apply the settings to the capitals, unless that's the effect you want.
Step 3: Apply the above settings manually or via or Character Style.
Problem 1: How do I rid my Character Style of the font size so that only the scaling factors remain? As it is, if I want to apply small-caps to a different font size than the one I have set up, I have to manually change the font size after applying the style.
Problem 2: The scaling factors do not appear to work for changes in font size. When I used 24 pt and applied the above settings, the small-caps were too thin. The method only really works for a particular size, which in reality is all you would normally require.

Small Caps Problem

I use Helvetica Neue, and have for the last 4 years. Recently, whenever I change lower case type to small caps, funky looking characters show up. If I export to a PDF, the small caps are fine. What's happening?

Can you give us a screencap with an example?

Both Chinese and English in running header

Hi-
I have mixed Chinese and English in my book without any problems. However, I have one heading with both Chinese and English and the Chinese characters will not show in the running header, only crossed out squares.
Got any ideas? Lars

I'm back for a bit before I go out to walk the dog.
I've been looking at the screen captures you provided, and I'm almost ceertain I know what the problem is. I don't have the LiSong font, though, so I'm not 100% sure.
It looks to me like you are using a combination of the LiSong and Arno Pro, with your English text set in Arno Pro and the Chinese in LiSong. That's fine so far, it will probably also be OK if you are using LiSong for the English in the body text, too.
In your running headers you've switched to an italic font, and, I think, therein lies the problem. I'm certainly not versed in typesetting Chinese, but my understanding is that there are no italics, and it looks to me like the entire running header is set in Arno Pro italic. Arno Pro does not have any Chinese glyphs, so you get the x-boxes. If you select the variable for the chines text and change the font to the LiSong I think they will go away and your correct glyphs will return.
Also, it looks like you have the header repeating because you've got both the two character style variables and aparagraph style variable. You don't need the last one if you use the first two.
And finally, and I probably should have mentioned this earlier, the character styles applied to this text don't necessarily need to do anything at all tothe formatting to work for defineing variables, as long as they have unique names. This allows you to name different parts of a paragraph without affecting the text in any way, but you can then apply separate formatting to your individual variables. In this particualr case, if I'm correct that you are using ArnoPro for the English and LiSong for the Chinese in the body text, it's probably appropriate to create a "Chinese" character style that includes the LiSong font (but not a size or color so you can apply it anywhere in your text and it will match the surrounding type except for the face), and an "English" style that is only a name.

Why do text variables using Running Header character style translate forced returns as a word space in the running head on the first page but close up the space on subsequent pages?

In an InDesign document that requires 3 different Chapter head paragraph styles (to cope with differrent length headings) I've set up the running heads on the master page with a text variable using the Running header (character style) option. The character style I've assigned to this is an empty character style that is applied to all 3 chapter head paragraph styles.
Some chapter heads require a forced line break, so that the line breaks are aethesically pleasing. On the first page the text variable translates this forced line break as a word space in the running head, but on subsequent pages it ignores the forced line break. This means that if you have a word space before the forced line break, on the first page you get a double word space and on subsequent pages the running head sets correctly with a single word space. But if you remove the word space before the forced line break in the chapter head text, the first running head sets correctly with forced line break interpreted as a single word space, but on subsequest pages the space is closed up.
This only seems to be a problem when the character style option is used for header text variables. If a paragraph style is used the forrced line break is interpreted as a a single word space in all instances, both on the foirst page and subsequent pages.
This would appear to be a bug in how text variables are applied when using the Running header (character style) option. I can't see any other reason why the text variable would beheave differently on the first page and on subsequent pages. There is only one master page, so it isn't a case of their being an error between a main master page and a chapter opener master page.
Does anyone have any solutionss, or know if this problem has been fixed in subsequent releases of InDesign (I'm using CS6 ID version 8.0)
Thanks

Ask in the ID forum...
Mylenium

Generating mixed case for table and column names

I trying to get table definition from Oracle 9i database into my toplink workbench
(version 9.0.3), the column names and table names are capitilized by
default, how do I change this to be mixed case? Thanks

I'm not sure why you want them changed. The Oracle database by default is case insensitive, which in essence means it converts everything to upper case when a case is not specified (which can be done by wrapping it in quotes). Unfortunately, Java strings are case sensitive. This means that if you try searching resultsets for "TableName" when the database driver is returning "TABLENAME", you will run into problems. It is probably better to have your project match your database as closely as possible to avoid any issues later on.
That said, I don't know of a way to automatically have the workbench use mixed case names - it uses the strings as they are returned from the database. I believe you will need to manually change the table names if you want them to be different than what you have imported.
Best Regards,
Chris

Small caps stuck ON?

it appears i have a toggle set to "ON" and don't know how to turn it off. all my text is coming in with small caps instead of lower case no matter what font i choose. i can't find a setting for this. anybody know how to fix this? i'm using pse 2.0.

thanks, guys, i think i found the solution. i clicked on the text tool, then right-clicked over the first tile on the text tool bar (it has a capital "t" on it). a menu popped up with "reset tool" as one of the options. i clicked that option and it seems to be working properly now. not sure how i toggled to small caps to begin with, but my main problem seems to be solved now. thanks again for your suggestions.

Fetching data from database in case of mixed case in SE37

Hi,
I have created a function module(in se37) where the input is Last name(PA0002-NACHN). My requirement is i have to fetch data from PA0002 based on last name. But the problem is if i give a name in mixed case(both upper and lower) sap converts the last name into Capital letter and starts searching the database.
 But i tried in abap editor. here SAP accept the parameter(last name) as mixed case and starts searching. Why in function module the parameters are converted into upper case. How to restrict it.
 If i will create a domain with LOWER CASE check box checked and try to call the dataelement in import part of function module then also it's converting it inot upper case. If i uncheck the lower case check box then also it's taking it as upper case.
 How to process the input parameter in function module(SE37) which should take the input as user enters,i.e if user enters small letter it should take it as small letter , if mixed letter it should take it as mixed letter and start searching.
regards
sandeep

HI sandeep,
"If i will create a domain with LOWER CASE check box checked and try to call the dataelement in import part of function module then also it's converting it inot upper case. If i uncheck the lower case check box then also it's taking it as upper case."
I think the data is getting converted to upper case even before it is passed to this FM.
Can yo ushow how are you testing this FM?
If you are calling this FM in a abap program using a parameter, it will convert the text to upper case as and when you enter data the name in it.
Regards,
Ravi

BUG: Export DDL and Data fails for mixed case table/column names

Hi there,
I have found a bug in SQL Developer. See details below.
Description:
When "Export DDL and Data) function is used on a table/columns not named in UPPERCASE, sql generated by SQL Developer is invalid.
Steps to reproduce:
- open SQL Developer, connect to DB
- make a table named "lowerCase" (in double quotes, so it won't be automatically changed to capital letters)
- you may also add some columns, for example "lowerCol1", "UpCol2", ALLUPCOL3
- add some data rows to the table
- choose Tools -> Export DDL and Data
- check exporting of tables and data, on "filter" tabs choose your "lowerCase" table
- press "Apply"
Error:
Generated SQL contains invalid INSERTs: mixed-case table and columns are referenced without obligatory double quotes, which yields an error when generated script is executed (see below, relevant line is underlined)
-- DDL for Table lowerCase
CREATE TABLE "DBO_HT"."lowerCase"
(     "lowerCol1" VARCHAR2(100),
     "UpCol2" VARCHAR2(100),
     "ALLUPCOL3" VARCHAR2(100)
-- DATA FOR TABLE lowerCase
-- FILTER = none used
-- INSERTING into lowerCase
Insert into lowerCase (lowerCol1,UpCol2,ALLUPCOL3) values ('lc','uc','auc');
-- END DATA FOR TABLE lowerCase
Remarks
SQL Developer: version 1.2.1, build MAIN-32.13
Oracle DBs: 9.2 & Express
OS: Windows 2000 Professional
If you need any more details/testing, let me know. I'd really appreciate a quick patch for this issue...
Alternatively, do you know of any other simple way of copying a single database (it's called a schema in Oracle, right?) from one computer to another? Possibly something so simple like detaching->copying->reattaching mdf (data) files in SQL Server... I thought that this "Export DDL&Data" function will do, but as you can see I couldn't use it.
I just need a simple solution that works - one operation on source to stuff, get the resulting files to other computer and one operation to have it running there... I think that such scenario is very basic, yet I just can't achieve it and I am simply not allowed to spend more time on it (read: our test project fails, my company rejects my "lobbying" and stays with MSSQL :/ )
Thanks a lot & bye

Thanks for your reply.
ad. 1)
You're right. I just wanted to give some very short feedback on my experiences with SQL Developer, so I didn't think starting new threads would be necessary, but as I was writing it became much bigger than I initially planned - sorry about that. I will make proper threads as soon as possible. Having "Edit post" button on this forum would also be useful.
ad. 2)
Generally, you're right - in most cases it's true that "switching DBMS is a major commitment" and "you will produce terrible code" if you don't learn the new one.
However, I think that you miss one part of market here - the market that I think Express is also targeted on. I'd call it a "fire&forget databases" market; MySQL comes to mind as possibly most common solution here. It's the rather small systems, possibly web-accessed, whose data-throughput requirements are rather modest; the point is to store data at all, and not necesarily in fastest way, because given the amount of data that is used, even on low-end hardware it will work well enough. What's important here is its general ease of use - how easy is to set up such system, connect and access data, develop a software using it, how much maintenance is needed, how easy this maintenance is, how easy are the most common development tasks as creating a DB, moving a DB from test to production server etc. There, "how easy" directly translates to "how much time we need to set it up", which translates to "how much will the development will cost".
Considering the current technology, switching the DBMS in such systems is not necesarily a major commitment and believe me that you will not produce terrible code. In many cases it's as simple as changing a switch in your ORM toolkit: hibernate.dialect = Hibernate.Dialect.OracleDialect vs MySQLDialect vs MsSql2005Dialect
Therefore, in some part of market it's easy to switch DBMS, even on project-by-project basis. The reason to switch will appear when other DBMS makes life easier => development faster. From that point of view, I can understand my colleagues giving me an embarassing look and saying "come on, I won't read all these docs just to have db copied to test server". And it doesn't mean "they are not willing to learn anything new", it's just that they feel such basic task should have self-explaining solution that doesn't require mastering any special knowledge. And if they get such simple solutions somewhere else, it costs them nothing to change the hibernate dialect.
I think Oracle did the great job with introducing the Express to this "fire&forget" market. The installation is a snap, it just works out of the box, nothing serious to configure, opposite to what I remember from installing and working on Oracle 9 a few years ago. In some places it's still "you need to start SQL*Plus and enter this script", but it's definitely less than before. I also find the SQL Developer a great tool, it can do most of what we need to do with the DB, it's also much better and pleasant to use over Oracle 9 tools. Still, a few basic things still require too much hassle, and I'd say taking your schema to another machine is one of them. So I think that, if you do it well, the "schema copy wizard" you mentioned might be very helpful. If I was to give any general advice for Express line of DB/tools, I'd say "make things simple" - make it "a DB you can't see".
That's, IMHO, the way to attract more Express users.

Photoshop CS3 can't do lowercase type-only large and small caps

Photoshop CS3, G5 PowerMac Dual 2GHz w/ 7GB RAM
A weird Photoshop problem: using the type tool, I can only produce type in large-and-small-caps, as opposed to upper and lower case. I can't generate any lowercase text. I've tried all the usual diagnostic tools: trashing the prefs seemed to work at first, but it's destructive of other stuff I don't want to lose, and anyway the problem came back after a while. I tried the Phantom User, and learned that the problem is tied to my User Identity, i.e., the problem doesn't exist in other User identities, but how do I make use of that information? I considered migrating to a new user identity, but I would have to go through every single appliciation, blah blah blah. So: does anybody have a quick, elegant solution to this, or is this a problem that has suddenly cropped up elsewhere? I'm not crippled by it, thanks to Illustrator CS3, but it's a convenience that I miss. And how do I trash the PS prefs without losing my brush tool presets?

Birck, >trashing the prefs seemed to work at first, but it's destructive of other stuff I don't want to lose, What "destruction" are you talking about? >and anyway the problem came back after a while. I assume this happens with fonts other than those (such as Trajan Std) that were designed with just caps and small caps. It sounds like it may be a duplicate or corrupted font issue. Did you use a good font manager to check for duplicate or corrupted fonts? Did you clear font caches (with Cocktail)? > tried the Phantom User, I see a black mask, cape and scary organ music here. <g> If logging in as a new user clears the problem, you may have a corrupted user identity and should stop using it. Neil

Small caps not working in web fonts

Hi everyone,
I'm having a problem implementing OpenType features in web fonts. No matter what typeface or browser I use—and I've tried several of each—I can't get the CSS font-face property to listen to font-variant:small-caps. In every case, the browser synthesizes its own small caps by scaling the full caps, which of course looks terrible.
The typefaces I've tried with this are all open-source advanced fonts: Cabin, Cardo, Lato, and Sorts Mill Goudy, all of which support small caps at least in their roman, regular-weight face. I've used Firefox 5, Opera 11.5, and the latest build of Iron (Chrome without Big Brother), all to no avail.
It's worth mentioning that other properties of advanced web typography, such as automatic ligatures (as well as the font-face property itself), are all working.
You can see my test page at http://www.utcolmus.org/test.html , and the CSS file at http://www.utcolmus.org/main.css. Any help would be greatly appreciated!
Thanks,
Bram

Yeah, that doesn't work.
CSS 3 supports directly accessing real small caps. Currently only Firefox supports this, and only via moz-prefixed properties (which makes sense as CSS 3 isn't final yet).
http://hacks.mozilla.org/2010/11/firefox-4-font-feature-support/

Small Caps ePub Issue

I am working on putting text into the ePub format and keep running into the same issue.
I want the title of the chapter to utilize Small Caps. Within InDesign I've got it look exactly the way I wish for it to - "Chapter One" appearing with small caps.
I've Highlighted the phrase "Chapter One" and applied a paragraph style that has the following features:
[no paragraph style] + next [same style] + Times New Roman + size: 24 pt + small point
When I export to ePub to view the document in Adobe Digital Editions these changes are not present. I've tried just about everything from applying character styles and nested styles, but nothing is working. I'd like these Small Cap appearances to work in the ePub versions as well.
Any thoughts on why this is not working?
Any help is much appreciated. Scouring the internet for a while has not turned up any advice.
Thanks in advance.

Hi- I have a problem with small caps and epub export too, in InD 5.0.
I defined a style with a nested stye that applies small caps for the first four words. I see this definition in the CSS output by InD:
span.no-style-override-2 {
font-variant: small-caps;
I do not see this style applied in any of the content. If I manually code it in:
Eric and Kate, young ....
it is correctly displayed. I'd like to get InDesign to export it correctly. I notice the same behavior in 5.5.
What can I do to have my nested style properly marked up in the epub export?
Thanks.

Small caps in running heads - mixed case problem

Similar Messages

Maybe you are looking for