Als ik in indesign iets op een coordinaat zet (iig iets dat een maat heeft) dan wordt de maat afgerond naar 6 cijfers achter de komma?!
vb: 10,5 mm wordt 10,505050

In illustrator staat voor elke 0 een min
vb: 0 mm is -0 mm

Heeft iemand hier enige ervaring mee? En mij dan kan helpen?

Thanx Kevin

Dat is een bekende ‘bug’. Heeft te maken met het feit dat InDesign (en ook andere Adobe-apps) alle eenheden heen– en terugrekent naar een vaste, intern gebruikte eenheid (de punt, maar dan die van 72 per inch, niet een pica- of didotpunt). Daardoor krijg je afrondingsverschillen. Niets van aantrekken, dus.

Dat minnetje bij Illustrator is mij trouwens onbekend.

Misschien kun je hierover iets vinden in de Adobe Fora?

Bij illustrator ken ik wel de irritante afrondingsverschillen, maar InDesign heeft er volgens mij geen last van. Ook de -0 ken ik niet van Illustrator.

Alleen als je een kader een lijn meegeeft kan je cijfers achter de komma verwachten, maar dat klopt dan ook. Dat is te vermijden door via het Control panel (die waar je ook maten en zo ingeeft), het driehoekje en 'Dimensions include strokeweight' uitvinken.

Oeps, dat had ik dus niet gezien — logisch, de helft van de lijndikte gaar van de coordinaat af, of komt erbij.

Dan lijkt het mij makkelijker om "Lijn op binnenkant uitlijnen" aan te vinken en inderdaad "Afmeting incl. lijndikte" uit te vinken. Zo heb je geen last van coordinaten die verspringen of brak afgerond worden.

Dat laatste vind ik dan weer niet handig met handmatig 'trappen' van kaders (bijv. zwart of zilver/goud). 't kan ook zijn dat ik ouderwetsch ben.  

Handmatige trapping is zoooo jaren '90      

Lach maar,

tot je met meerkleurendruk te maken krijgt. Gaat in 90% faliekant fout bij de meeste trapping software. En dus bij en ongeschoolde windowsjonkies* van de drukkerij.

Dan komen oude wijsheden en stoffige kennis weer tot leven.  

* Zie Grafische school Eindhoven.

(Bewerkt door TB om 16:43, 12-04-2006)

inderdaad. Bij gebruik van pantonekleuren kan je maar beter handmatig "trappen".
Zelfs in Indesign...

Eeuhm, sorry hoor, dat kan best zo zijn maar hier draaien we zonder problemen CMYK+PMS+LAK via volledig automatische trapping. Nagenoeg zonder problemen op heel af en toe een uitzondering na (maar die bevestigt de regel toch? .

@TB: ik had er niet voor niets maar liefst DRIE emoticons bijgezet, het was geen aanval op een oude weerloze man hoor  

Oude, (let op die komma) weerloze man?            

Zonder gekheid: cmyk, Pantone (de meeste) en lak zijn natuurlijk geen probleem. Het gaat om de kleuren die niet in dat straatje passen. Dan werken de standaardinstelling van de trappingssoftware en/of ctp systemen niet goed meer. Zet maar eens een zwarte tekst op zilver. Of bij gebruik van merkkleuren (eigen menging). Een onbekende kleurnaam kan een bak roet over het eten heenstrooien.

Het frappante is dat ik/wij dit soort 'problemen' de laatste maanden vaker tegengekomen zijn dan vroeger. Vandaar de opmerking over de windowsjonkies. Als de standaardtrapping niet werkt, beginnen ze bij de drukkerijen te steigeren. Tja.

Dit berichtje express met Win XP geschreven. Gewoon om gPod te pesten. Ik vijfendertig jonge jaartjes

Ik zag inderdaad dat je nog helemaal niet zo oud (laat staan weerloos) bent.  

En met Win XP gebruiken pest je toch alleen maar jezelf?  

Back on-topic: Regelmatig wordt hier goud gedrukt als extra drukgang (dus CMYK+GOUD) maar met automatische trapping wordt dat alsnog perfect sluitend afgeleverd. Eigen mengkleuren moeten sowieso aan een bekende (meestal pms) kleur gehangen worden, hij moet in ieder geval in de staalbibliotheken van de pdf-workflow voorkomen, anders herkent de software deze niet en dan zou inderdaad de trapping niet goed berekend kunnen worden.

Keuzes, keuzes, keuzes en... overgangen !
Het is deels afhankelijk van wie de klus aan wie vertrouwt of overlaat
en deels een kwestie van welke versies je in een workflow aan houdt.
Het is 'trend' om steeds minder in te stellen, wanneer je met nieuwere
PDF-versies werkt en PDF-RIP zijn eigen instelling erover mag gooien.
Deze instellingen zijn nauwkeuriger dan de 'ouwe' PostScript-methode
(waarbij je vrijwel alles zelf moest/mocht zeggen). Dat is de overgang.
Iets 'aparts' kan je alsnog zelf aangeven maar dan moet je dit wel van
voor tot achter in een níeuwere workflow melden, anders gaat het mis.
Dat soort lekker verwarrende keuzes en trends spelen dus een rol.

TB om 15:20, 11-04-2006
... Dat is te vermijden door via het Control panel (die waar je ook maten en zo ingeeft), het driehoekje en 'Dimensions include strokeweight' uitvinken.

Ik zoek me een ongeluk, kan het niet vinden. 'Dimensions include strokeweight' staat er niet bij in mijn Illustat. CS2. Ik kijk bij het Control palette, de Voorkeuren en bij 'Stroke'.

Kan iemand dat verduidelijken?

In het control palette uiterst rechts staat een driehoekje, aanklikken en daar zou de optie "Dimensions include strokeweight' toch echt moeten staan.

@ gPod (en andere geïnteresseerden),

Onderstaand plaatje is wat ik zie bij het driehoekje van het Control palette... nope

Eeeuhm, dat ging natuurlijk niet over Illustrator maar over InDesign...  

edit: bij Illustrator is "Dimensions include strokeweigth" namelijk standaard....

(Bewerkt door gPod om 12:21, 13-04-2006)

Dank je gPod. Het draadje gaat over ID en Illustrator, ik was helemaal op Illy gefocused.

gPod om 12:18, 13-04-2006
... edit: bij Illustrator is "Dimensions include strokeweigth" namelijk standaard....
(Bewerkt door gPod om 12:21, 13-04-2006)

Hier geeft Illustrator CS2 (zojuist schoon geïnstalleerd op iBookje) de afmetingen weer zonder rekening te houden met eventuele lijndikte (dus alleen de afmetingen van het draadmodel).

Sorry, ik bedoelde inderdaad standaard zonder 'dimensions include strokeweight'.... De lijndikte heeft geen effect op de afmeting van een object.

Maaarrre, wat betreft al die cijfers achter de komma is er geen oplossing te vinden? Want ik heb hetzelfde probleem.
En ik vind het zwaar irritant dat als ik een kader op 10 cm zet, indesign er 10,003243 van maakt. (dat noem ik nu helemaaal niet nauwkeurig, juist slordig....)

Nogmaals:
Alle meetwerk wordt in de kern van de PDF- en PostScript-taal
teruggebracht naar eenheden in Amerikaanse inches en punten.
Ergens zit er dus een afronding. Tot op zekere hoogte houdt de
software daar rekening mee (bijv. bij magnetische hulplijnen),
maar als je de expliciete maten opvraagt, blijkt de afronding.

Een mm-maat wordt omgezet naar de punt-maat met 4 cijfers
achter de komma. Maar daarnaast onthoudt de software vaak
ook dat je oorspronkelijk mm wilde en zal dat ook aanhouden.
100 blokjes herhalen de fout dus niet 100x maar worden 100x
op dichtstbijzijnde punt-maat afgerond. Lig er niet van wakker...

oke, ik zal mij er maar niet meer druk om maken. Dank voor je uitleg
groeten

Maar het blijft een irritant probleem.

Ik heb het nu zelf gezien bij een ander (Een InMac, wellicht dat het daar aan ligt?). Helaas geen tijd gehad om te bekijken waar het in zat.

En sorry, ik heb het probleem dus niet. Alles netjes afgerond en niet meer dan 3 cijfertjes achter de komma van te maken.

Ik heb op een Adobe Forum gelezen dat het bij (met name?) de IntelMacs een bekende bug is, die misschien verholpen kan worden door voor de weergave van maten de optie "Lijndikte meerekenen" (ik parafraseer, weet niet hoe het precies heet, maar het moet te vinden zijn) UIT te zetten.

O ja, die Intel waren ooit negatief in het nieuws gekomen
omdat ze rekenden dat 1 + 1 = 2,000039 of zoiets, toch ?
Misschien dat de EU ook BTW wil gaan heffen op de inches
(ze willen 0,00001 cent BTW op verzonden emails heffen...)