FM9 and Russian Translation Problems

2010-06-21 Thread Alison Craig 
FM 9 Version: 9.0p250
Unstructured
OS: XP Pro with SP3
FM Experience: 12 months
Translation/Localization Management Experience: 11 years
Writing Team: 1 (me)

I have just received my Russian User Manual translation back from the LSP and 
am encountering problems I haven't seen with any other language in FM. (I've 
handled Russian, Greek and Bulgarian in Word so I'm experienced with Cyrillic 
languages in general, but not specifically in FM.)

I may have to make the LSP fix these issues, but in the meantime, if anyone has 
any insight I would appreciate it. At the very least I would like to understand 
the issue.

PROBLEM 1
---
Although the auto-numbering of my Heading Para Tags appears to be correct - ie, 
identical to the English version - they are not showing up properly.

  ENGLISH RUSSIAN
Heading 1 A:Chapter n+: А:Глава n+:
Heading 2 A:n.n+\tA:n.n+\t
Heading 3 A:n.n.n+\tA:n.n.n+\t
Heading 4 A:n.n.n.n+\tA:n.n.n.n+\t


All Heading 1 Para Tags shows up correctly (with the word Chapter translated to 
Russian and the correct Chapter number) but Headings 2 to 4 are wrong. They all 
begin with 0.

Also, Heading 2, does not start to renumber itself in chapter 2. All Heading 2 
numbering throughout the book is sequential from the first Heading 2 in Chapter 
1. Within each chapter, Heading 3 seems to be sequential to the proceeding 
Heading 2, but it still has the goofy 0. numbering.

Appendices are wrong as well. Heading 1App is correct (with a letter instead of 
a number), but Heading2 App still leads with a 0. The only good thing is the 
Heading 2App starts numbering from the beginning (0.1) rather than continuing 
the numbering from the Chapters - however, all Heading 2App Para Tags are 
sequentially numbered within all Appendices just as they are within all 
Chapters.

Interestingly, Tables and Figures are handled correctly, although they actually 
specify the use of $chapnum

F:Figure $chapnum\+n=1:
F:Рисунок $chapnum\+n=1:


PROBLEM 2
---
Is there any way to do a wholesale change to language settings? Instead of 
being set to Russian (or русско), all the Para and Char Tags seem to be set to 
None.

If I can't automate a fix to this (and I don't have FrameScript), I will 
definitely have to make the LSP fix it.
-

Any help is appreciated, Alison

Alison Craig, Technical Writer
Ultrasonix Medical Corporation
130 - 4311 Viking Way
Richmond, BC  V6V 2K9
Tel: (604) 279-8550, ext 127
Fax: (604) 279-8559
E-mail: alison.cr...@ultrasonix.commailto:alison.cr...@ultrasonix.com


___


You are currently subscribed to framers as arch...@mail-archive.com.

Send list messages to fram...@lists.frameusers.com.

To unsubscribe send a blank email to
framers-unsubscr...@lists.frameusers.com
or visit 
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com

Send administrative questions to listad...@frameusers.com. Visit
http://www.frameusers.com/ for more resources and info.

Re: FM9 and Russian Translation Problems

2010-06-21 Thread Jeremy H. Griffith 
On Mon, 21 Jun 2010 11:21:37 -0700, Alison Craig alison.cr...@ultrasonix.com 
wrote:

FM 9 Version: 9.0p250
Unstructured
OS: XP Pro with SP3
FM Experience: 12 months
Translation/Localization Management Experience: 11 years
Writing Team: 1 (me)

I have just received my Russian User Manual translation back from 
the LSP and am encountering problems I haven't seen with any other 
language in FM. (I've handled Russian, Greek and Bulgarian in Word 
so I'm experienced with Cyrillic languages in general, but not 
specifically in FM.)

I may have to make the LSP fix these issues, but in the meantime, 
if anyone has any insight I would appreciate it. At the very least 
I would like to understand the issue.

PROBLEM 1
---
Although the auto-numbering of my Heading Para Tags appears to be 
correct - ie, identical to the English version - they are not 
showing up properly.

  ENGLISH RUSSIAN
Heading 1 A:Chapter n+: ?:? n+:
Heading 2 A:n.n+\tA:n.n+\t
Heading 3 A:n.n.n+\tA:n.n.n+\t
Heading 4 A:n.n.n.n+\tA:n.n.n.n+\t


All Heading 1 Para Tags shows up correctly (with the word Chapter 
translated to Russian and the correct Chapter number) but Headings 
2 to 4 are wrong. They all begin with 0.

That (and the other two problems related to this) are all because the
Russian Heading 1 does not have the same series letter, A, as the
others.  Series letters should **not** be translated.

Interestingly, Tables and Figures are handled correctly, although 
they actually specify the use of $chapnum

F:Figure $chapnum\+n=1:
F:??? $chapnum\+n=1:

Here, they did *not* translate the series letter.


PROBLEM 2
---
Is there any way to do a wholesale change to language settings? 
Instead of being set to Russian (or ??), all the Para and 
Char Tags seem to be set to None.

If I can't automate a fix to this (and I don't have FrameScript), 
I will definitely have to make the LSP fix it.

I'm pretty sure you can do that by opening the para designer,
setting it to As Is, changing the one language setting, and
applying it globally.  But I don't have 9 handy to check on.

-

Any help is appreciated, Alison

HTH!

-- Jeremy H. Griffith, at Omni Systems Inc.
  jer...@omsys.com  http://www.omsys.com/
___


You are currently subscribed to framers as arch...@mail-archive.com.

Send list messages to fram...@lists.frameusers.com.

To unsubscribe send a blank email to
framers-unsubscr...@lists.frameusers.com
or visit 
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com

Send administrative questions to listad...@frameusers.com. Visit
http://www.frameusers.com/ for more resources and info.

RE: FM9 and Russian Translation Problems - SOLVED

2010-06-21 Thread Alison Craig 
Jeremy: 

Actually, I don't think they did translate the A. I substituted $chapnum 
for n+ without changing the A and now the headings work just fine. (The one 
that looks like a ? below got mangled when my HTML e-mail was turned into 
plain text.)

Following a suggestion from another Frame List helper I also ensured that the 
numbering settings I required were up-to-date then updated the book (when I did 
that *before* I used the $chapnum substitution, it just made the whole mess 
even worse). 

Someone else has given me some pointers on global language changes which solved 
that problem as well.

I love this list!

Alison

Alison Craig, Technical Writer
Ultrasonix Medical Corporation
Tel: (604) 279-8550, ext 127
E-mail: alison.cr...@ultrasonix.com

-Original Message-
From: Jeremy H. Griffith [mailto:jer...@omsys.com] 
Sent: Monday, June 21, 2010 2:40 PM
To: framers@lists.frameusers.com
Cc: Alison Craig
Subject: Re: FM9 and Russian Translation Problems

On Mon, 21 Jun 2010 11:21:37 -0700, Alison Craig alison.cr...@ultrasonix.com 
wrote:

FM 9 Version: 9.0p250
Unstructured
OS: XP Pro with SP3
FM Experience: 12 months
Translation/Localization Management Experience: 11 years
Writing Team: 1 (me)

I have just received my Russian User Manual translation back from 
the LSP and am encountering problems I haven't seen with any other 
language in FM. (I've handled Russian, Greek and Bulgarian in Word 
so I'm experienced with Cyrillic languages in general, but not 
specifically in FM.)

I may have to make the LSP fix these issues, but in the meantime, 
if anyone has any insight I would appreciate it. At the very least 
I would like to understand the issue.

PROBLEM 1
---
Although the auto-numbering of my Heading Para Tags appears to be 
correct - ie, identical to the English version - they are not 
showing up properly.

  ENGLISH RUSSIAN
Heading 1 A:Chapter n+: A:? n+:
Heading 2 A:n.n+\tA:n.n+\t
Heading 3 A:n.n.n+\tA:n.n.n+\t
Heading 4 A:n.n.n.n+\tA:n.n.n.n+\t


All Heading 1 Para Tags shows up correctly (with the word Chapter 
translated to Russian and the correct Chapter number) but Headings 
2 to 4 are wrong. They all begin with 0.

That (and the other two problems related to this) are all because the
Russian Heading 1 does not have the same series letter, A, as the
others.  Series letters should **not** be translated.

Interestingly, Tables and Figures are handled correctly, although 
they actually specify the use of $chapnum

F:Figure $chapnum\+n=1:
F:??? $chapnum\+n=1:

Here, they did *not* translate the series letter.


PROBLEM 2
---
Is there any way to do a wholesale change to language settings? 
Instead of being set to Russian (or ??), all the Para and 
Char Tags seem to be set to None.

If I can't automate a fix to this (and I don't have FrameScript), 
I will definitely have to make the LSP fix it.

I'm pretty sure you can do that by opening the para designer,
setting it to As Is, changing the one language setting, and
applying it globally.  But I don't have 9 handy to check on.

-

Any help is appreciated, Alison

HTH!

-- Jeremy H. Griffith, at Omni Systems Inc.
  jer...@omsys.com  http://www.omsys.com/
___


You are currently subscribed to framers as arch...@mail-archive.com.

Send list messages to fram...@lists.frameusers.com.

To unsubscribe send a blank email to
framers-unsubscr...@lists.frameusers.com
or visit 
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com

Send administrative questions to listad...@frameusers.com. Visit
http://www.frameusers.com/ for more resources and info.

A Graphics Library...Why?

2010-06-21 Thread Eduardo F. Cidade, Sr. 
Good evening fellow Framers and Frame Templars

I've built a specification for a Standard Operating Procedure (SOP)
regarding building a Graphics Library (call it a database, tracker,
whatever).

One thing that gnaws at this old writer is the standard question:  Why?

I could use reasons such as:
Traceability
Locating Graphics
Documentation Mapping

It's just eluding me as to a rock-solid answer on this.

Just reaching out to you all for some input or a resource I can tap.  I have
the procedure and policy and framework (no pun intended) in place but in
doing this, I also know internal auditors will ask the pervasive question,
Why?

Have a safe and interesting evening.

From Forest Hills, NY

Eduardo



I'm just another writer, still trapped within my truth;
A hesitant prize fighter, still trapped within my youth. 
   Dan Hill


___


You are currently subscribed to framers as arch...@mail-archive.com.

Send list messages to fram...@lists.frameusers.com.

To unsubscribe send a blank email to
framers-unsubscr...@lists.frameusers.com
or visit 
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com

Send administrative questions to listad...@frameusers.com. Visit
http://www.frameusers.com/ for more resources and info.

Re: A Graphics Library...Why?

2010-06-21 Thread Mollye Barrett 
Depends on functionality... I use a graphics tracker for file management
with thumbnails for accurate identification and a format conversion
generator for multiple formats. Powered by a database, each graphic has
searchable metadata, automated file numbering and version control. This is
especially important for layered graphics with standard base drawings.
Also excellent for associating with assembly numbers and other where-used
information. A graphics tracker is aabsolutely essential when working with
equipment and engineering graphics.

-- 
Mollye Barrett
ClearPath, LLC
414-331-1378 (cell)
www.clearpath.cc
http://www.linkedin.com/in/mollyebarrett
http://www.twitter.com/mollye


On Mon, Jun 21, 2010 at 8:28 PM, Eduardo F. Cidade, Sr. 
ecid...@zoominternet.net wrote:

 Good evening fellow Framers and Frame Templars

 I've built a specification for a Standard Operating Procedure (SOP)
 regarding building a Graphics Library (call it a database, tracker,
 whatever).

 One thing that gnaws at this old writer is the standard question:  Why?

 I could use reasons such as:
 Traceability
 Locating Graphics
 Documentation Mapping

 It's just eluding me as to a rock-solid answer on this.

 Just reaching out to you all for some input or a resource I can tap.  I
 have
 the procedure and policy and framework (no pun intended) in place but in
 doing this, I also know internal auditors will ask the pervasive question,
 Why?

 Have a safe and interesting evening.

 From Forest Hills, NY

 Eduardo



 I'm just another writer, still trapped within my truth;
 A hesitant prize fighter, still trapped within my youth.
   Dan Hill


 ___


 You are currently subscribed to framers as mol...@clearpath.cc.

 Send list messages to fram...@lists.frameusers.com.

 To unsubscribe send a blank email to
 framers-unsubscr...@lists.frameusers.com
 or visit
 http://lists.frameusers.com/mailman/options/framers/mollye%40clearpath.cc

 Send administrative questions to listad...@frameusers.com. Visit
 http://www.frameusers.com/ for more resources and info.

___


You are currently subscribed to framers as arch...@mail-archive.com.

Send list messages to fram...@lists.frameusers.com.

To unsubscribe send a blank email to
framers-unsubscr...@lists.frameusers.com
or visit 
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com

Send administrative questions to listad...@frameusers.com. Visit
http://www.frameusers.com/ for more resources and info.

Graphics Library

2010-06-21 Thread Gary Bankston 
Because it saves you time and them money, while adding consistency to the
documentation graphics.
___


You are currently subscribed to framers as arch...@mail-archive.com.

Send list messages to fram...@lists.frameusers.com.

To unsubscribe send a blank email to
framers-unsubscr...@lists.frameusers.com
or visit 
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com

Send administrative questions to listad...@frameusers.com. Visit
http://www.frameusers.com/ for more resources and info.

RE: A Graphics Library...Why?

2010-06-21 Thread Combs, Richard 
Eduardo F. Cidade, Sr., wrote:
 
 I've built a specification for a Standard Operating Procedure (SOP)
 regarding building a Graphics Library (call it a database, tracker,
 whatever).
 
 One thing that gnaws at this old writer is the standard question:  Why?
 
 I could use reasons such as:
 Traceability
 Locating Graphics
 Documentation Mapping
 
 It's just eluding me as to a rock-solid answer on this.

No offense, but didn't you put the cart before the horse? The normal procedure, 
IMHO, is to determine the need first, and then create the business case and 
define the requirements, and _only then_ design the thing. 

I'm reminded of those software engineers I've dealt with who, _after_ they've 
completed a new feature, write requirements to match what they've done. :-) 


Richard G. Combs
Senior Technical Writer
Polycom, Inc.
richardDOTcombs AT polycomDOTcom
303-223-5111
--
rgcombs AT gmailDOTcom
303-903-6372
--






___


You are currently subscribed to framers as arch...@mail-archive.com.

Send list messages to fram...@lists.frameusers.com.

To unsubscribe send a blank email to
framers-unsubscr...@lists.frameusers.com
or visit 
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com

Send administrative questions to listad...@frameusers.com. Visit
http://www.frameusers.com/ for more resources and info.

FM9 and Russian Translation Problems

2010-06-21 Thread Alison Craig 
FM 9 Version: 9.0p250
Unstructured
OS: XP Pro with SP3
FM Experience: 12 months
Translation/Localization Management Experience: 11 years
Writing Team: 1 (me)

I have just received my Russian User Manual translation back from the LSP and 
am encountering problems I haven't seen with any other language in FM. (I've 
handled Russian, Greek and Bulgarian in Word so I'm experienced with Cyrillic 
languages in general, but not specifically in FM.)

I may have to make the LSP fix these issues, but in the meantime, if anyone has 
any insight I would appreciate it. At the very least I would like to understand 
the issue.

PROBLEM 1
---
Although the auto-numbering of my Heading Para Tags appears to be correct - ie, 
identical to the English version - they are not showing up properly.

  ENGLISH RUSSIAN
Heading 1 A:Chapter : ?:? :
Heading 2 A:.\tA:.\t
Heading 3 A:..\tA:..\t
Heading 4 A:...\tA:...\t


All Heading 1 Para Tags shows up correctly (with the word Chapter translated to 
Russian and the correct Chapter number) but Headings 2 to 4 are wrong. They all 
begin with 0.

Also, Heading 2, does not start to renumber itself in chapter 2. All Heading 2 
numbering throughout the book is sequential from the first Heading 2 in Chapter 
1. Within each chapter, Heading 3 seems to be sequential to the proceeding 
Heading 2, but it still has the goofy 0. numbering.

Appendices are wrong as well. Heading 1App is correct (with a letter instead of 
a number), but Heading2 App still leads with a 0. The only good thing is the 
Heading 2App starts numbering from the beginning (0.1) rather than continuing 
the numbering from the Chapters - however, all Heading 2App Para Tags are 
sequentially numbered within all Appendices just as they are within all 
Chapters.

Interestingly, Tables and Figures are handled correctly, although they actually 
specify the use of <$chapnum>

F:Figure

FM9 and Russian Translation Problems

2010-06-21 Thread Jeremy H. Griffith 
On Mon, 21 Jun 2010 11:21:37 -0700, Alison Craig  
wrote:

>FM 9 Version: 9.0p250
>Unstructured
>OS: XP Pro with SP3
>FM Experience: 12 months
>Translation/Localization Management Experience: 11 years
>Writing Team: 1 (me)
>
>I have just received my Russian User Manual translation back from 
>the LSP and am encountering problems I haven't seen with any other 
>language in FM. (I've handled Russian, Greek and Bulgarian in Word 
>so I'm experienced with Cyrillic languages in general, but not 
>specifically in FM.)
>
>I may have to make the LSP fix these issues, but in the meantime, 
>if anyone has any insight I would appreciate it. At the very least 
>I would like to understand the issue.
>
>PROBLEM 1
>---
>Although the auto-numbering of my Heading Para Tags appears to be 
>correct - ie, identical to the English version - they are not 
>showing up properly.
>
>  ENGLISH RUSSIAN
>Heading 1 A:Chapter : ?:? :
>Heading 2 A:.\tA:.\t
>Heading 3 A:..\tA:..\t
>Heading 4 A:...\tA:...\t
>
>
>All Heading 1 Para Tags shows up correctly (with the word Chapter 
>translated to Russian and the correct Chapter number) but Headings 
>2 to 4 are wrong. They all begin with 0.

That (and the other two problems related to this) are all because the
Russian Heading 1 does not have the same series letter, "A", as the
others.  Series letters should **not** be translated.

>Interestingly, Tables and Figures are handled correctly, although 
>they actually specify the use of <$chapnum>
>
>F:Figure

FM9 and Russian Translation Problems - SOLVED

2010-06-21 Thread Alison Craig 
Jeremy: 

Actually, I don't think they did translate the "A". I substituted <$chapnum> 
for  without changing the "A" and now the headings work just fine. (The one 
that looks like a "?" below got mangled when my HTML e-mail was turned into 
plain text.)

Following a suggestion from another Frame List helper I also ensured that the 
numbering settings I required were up-to-date then updated the book (when I did 
that *before* I used the <$chapnum> substitution, it just made the whole mess 
even worse). 

Someone else has given me some pointers on global language changes which solved 
that problem as well.

I love this list!

Alison

Alison Craig, Technical Writer
Ultrasonix Medical Corporation
Tel: (604) 279-8550, ext 127
E-mail: alison.craig at ultrasonix.com

-Original Message-
From: Jeremy H. Griffith [mailto:jer...@omsys.com] 
Sent: Monday, June 21, 2010 2:40 PM
To: framers at lists.frameusers.com
Cc: Alison Craig
Subject: Re: FM9 and Russian Translation Problems

On Mon, 21 Jun 2010 11:21:37 -0700, Alison Craig  
wrote:

>FM 9 Version: 9.0p250
>Unstructured
>OS: XP Pro with SP3
>FM Experience: 12 months
>Translation/Localization Management Experience: 11 years
>Writing Team: 1 (me)
>
>I have just received my Russian User Manual translation back from 
>the LSP and am encountering problems I haven't seen with any other 
>language in FM. (I've handled Russian, Greek and Bulgarian in Word 
>so I'm experienced with Cyrillic languages in general, but not 
>specifically in FM.)
>
>I may have to make the LSP fix these issues, but in the meantime, 
>if anyone has any insight I would appreciate it. At the very least 
>I would like to understand the issue.
>
>PROBLEM 1
>---
>Although the auto-numbering of my Heading Para Tags appears to be 
>correct - ie, identical to the English version - they are not 
>showing up properly.
>
>  ENGLISH RUSSIAN
>Heading 1 A:Chapter : A:? :
>Heading 2 A:.\tA:.\t
>Heading 3 A:..\tA:..\t
>Heading 4 A:...\tA:...\t
>
>
>All Heading 1 Para Tags shows up correctly (with the word Chapter 
>translated to Russian and the correct Chapter number) but Headings 
>2 to 4 are wrong. They all begin with 0.

That (and the other two problems related to this) are all because the
Russian Heading 1 does not have the same series letter, "A", as the
others.  Series letters should **not** be translated.

>Interestingly, Tables and Figures are handled correctly, although 
>they actually specify the use of <$chapnum>
>
>F:Figure

A Graphics Library...Why?

2010-06-21 Thread Eduardo F. Cidade, Sr. 
Good evening fellow Framers and Frame Templars

I've built a specification for a Standard Operating Procedure (SOP)
regarding building a Graphics Library (call it a database, tracker,
whatever).

One thing that gnaws at this old writer is the standard question:  Why?

I could use reasons such as:
Traceability
Locating Graphics
Documentation Mapping

It's just eluding me as to a rock-solid answer on this.

Just reaching out to you all for some input or a resource I can tap.  I have
the procedure and policy and framework (no pun intended) in place but in
doing this, I also know internal auditors will ask the pervasive question,
"Why?"

Have a safe and interesting evening.

>From Forest Hills, NY

Eduardo



"I'm just another writer, still trapped within my truth;
A hesitant prize fighter, still trapped within my youth." 
   Dan Hill

A Graphics Library...Why?

2010-06-21 Thread Mollye Barrett 
Depends on functionality... I use a graphics tracker for file management
with thumbnails for accurate identification and a format conversion
generator for multiple formats. Powered by a database, each graphic has
searchable metadata, automated file numbering and version control. This is
especially important for layered graphics with standard base drawings.
Also excellent for associating with assembly numbers and other where-used
information. A graphics tracker is aabsolutely essential when working with
equipment and engineering graphics.

-- 
Mollye Barrett
ClearPath, LLC
414-331-1378 (cell)
www.clearpath.cc
http://www.linkedin.com/in/mollyebarrett
http://www.twitter.com/mollye


On Mon, Jun 21, 2010 at 8:28 PM, Eduardo F. Cidade, Sr. <
ecidade at zoominternet.net> wrote:

> Good evening fellow Framers and Frame Templars
>
> I've built a specification for a Standard Operating Procedure (SOP)
> regarding building a Graphics Library (call it a database, tracker,
> whatever).
>
> One thing that gnaws at this old writer is the standard question:  Why?
>
> I could use reasons such as:
> Traceability
> Locating Graphics
> Documentation Mapping
>
> It's just eluding me as to a rock-solid answer on this.
>
> Just reaching out to you all for some input or a resource I can tap.  I
> have
> the procedure and policy and framework (no pun intended) in place but in
> doing this, I also know internal auditors will ask the pervasive question,
> "Why?"
>
> Have a safe and interesting evening.
>
> From Forest Hills, NY
>
> Eduardo
>
>
>
> "I'm just another writer, still trapped within my truth;
> A hesitant prize fighter, still trapped within my youth."
>   Dan Hill
>
>
> ___
>
>
> You are currently subscribed to framers as mollye at clearpath.cc.
>
> Send list messages to framers at lists.frameusers.com.
>
> To unsubscribe send a blank email to
> framers-unsubscribe at lists.frameusers.com
> or visit
> http://lists.frameusers.com/mailman/options/framers/mollye%40clearpath.cc
>
> Send administrative questions to listadmin at frameusers.com. Visit
> http://www.frameusers.com/ for more resources and info.
>

Graphics Library

2010-06-21 Thread Gary Bankston 
Because it saves you time and them money, while adding consistency to the
documentation graphics.

A Graphics Library...Why?

2010-06-21 Thread Combs, Richard 
Eduardo F. Cidade, Sr., wrote:

> I've built a specification for a Standard Operating Procedure (SOP)
> regarding building a Graphics Library (call it a database, tracker,
> whatever).
> 
> One thing that gnaws at this old writer is the standard question:  Why?
> 
> I could use reasons such as:
> Traceability
> Locating Graphics
> Documentation Mapping
> 
> It's just eluding me as to a rock-solid answer on this.

No offense, but didn't you put the cart before the horse? The normal procedure, 
IMHO, is to determine the need first, and then create the business case and 
define the requirements, and _only then_ design the thing. 

I'm reminded of those software engineers I've dealt with who, _after_ they've 
completed a new feature, write requirements to match what they've done. :-) 


Richard G. Combs
Senior Technical Writer
Polycom, Inc.
richardDOTcombs AT polycomDOTcom
303-223-5111
--
rgcombs AT gmailDOTcom
303-903-6372
--