-
Posts
4,130 -
Joined
-
Last visited
Everything posted by Wosven
-
Dashed Lines - Alignment and scaling
Wosven replied to firstdefence's topic in Feedback for the V1 Affinity Suite of Products
*Bump*- 3 replies
-
- width
- dashed lines
-
(and 3 more)
Tagged with:
-
Hi @seannymurrs In fact, for this I would process visually: not looking at the middle, but at the "blanks" around the image to get them nearly equal, so optically it'll look centered. It's like designing a "O". If you want it to look "round", only the void inside should be round or ovale (or regular with some calligraphies). When beginners tend to focusing on the exterior. It's the same for centering unregular shapes. Sometimes, it's better if you crop a small part too, to obtain such result.
-
Hardcopy output
Wosven replied to William Overington's topic in Pre-V2 Archive of Desktop Questions (macOS and Windows)
You found it! I never set metal tyle by hand. Bur the wood casing were they were ordered were used as decorative items to put on the wall and display collection of small objects (especially owls for my mother). Since PC/Mac weren't so common, and less printers (with black ink), we used all tricks possible (photocopies, markers for drawing roughts...) for our projects. When I begin working, computers were more spreads, but we send files and not PDF (or with?) to our printers. Long ago, we could find some sort of automatic printers, were you only had to put an USB key, choose a format, pay and wait for a folder of pictures to be printed instantly. Perhaps local photographs can provide such services? Or some other shop that print on T-shirt, etc. -
It's not a server configuration (servers allow access, read/write, etc. rights as usual). But the apps (Adobe/Office/Libreoffice suites add a specific .~[garbage_unique].lck or similar hidden file that it's able to reconize. (I'm not sure data about last modifications are contained in this file, but it's related to the ability to lock the file and to ask if you want to recover it if for some reason the app crashed or closed without saving.) If it was a server setting, the apps wouldn't be able to provide recovery options. Usually, if you delete the ".~…" file, you can open the unmodified one without problem (it's helpfull with corrupted recovered files dues to apps crashing: you can't open the recovery, but the one prior modifications). Since it's at apps level, and there's not anymore difference between files depending on OSes (only between apps), perhaps it's not a problem between OSes. (At work, there's PC & Mac and we use the same servers). An app like Adobe reader will lock the file without any visible (hidden!) file. You won't be able to overwrite ot move a PDF if it's opened in AR. Perhaps it's only modifying its properties to read-only. You're right about this (at least with old Office version — we sometime had to unlock/delete the locking file but I suspect it depends of the type of file system, new one contains more datas and seem better —, I hadn't this problem with Office365 and newer servers). With ID files, the files aren't locked for a specific user. Anyone wanting to open the file will be asked to recover the latest version after a crash. Since companies don't always update to the latest version — for different reasons —, one of the way to recover a corrupt file can be to open and recover the file in a superior version of the app (it's possible to keep 2 different versions on the same computer). If you delete or move the locking file, the file will open in the last saved version. It's working effectively and is the choice of different companies with a lot of experience. Today, and especially with the Covid, we have a world wide experience for remote work and accessing servers. People tend to use different options to have their files on the cloud (servers). It's important and easier to backup servers, than working locally and doing copies or using synchronization (for example, Microsoft OneDrive is useful but a pain, not really different of the Backup app we used in the past!). It would be nice for AD/AP/APub to be able to join this worflow (when we tested them, one of the first to stop using them did so because the apps weren't servers friendly).
-
It would be important to get the 3 (or four if the problem occur also on OS X) issues solved. Perhaps the app can lock the file and add in the same folder data about the user to which the file belong (to prevent other user modifying it, until it's saved and closed), and keep locally the modifications in some sort of history, till it's saved.
-
Hardcopy output
Wosven replied to William Overington's topic in Pre-V2 Archive of Desktop Questions (macOS and Windows)
Sorry, it was "homothetic", but the older I get the lazier I am, and instead of using a real dictionary, I used Google translate (is it me or is it worst each time I use it?), "homothétique" didn't get any result, but "omothétique" get one. I'm wondering if it doesn't try to create word from prefixes and known suffixes... 😱 I learn this word as a student, in typography course, when we needed to use a large print of a font (A4), and use geometrical means and tools to enlarge it to a "format raisin" sheet of paper (50 × 65 cm), keeping the blue construction strokes, and using ruling pens and brushes to paint it in gouache. We learn a lot of interesting tricks in this pre-computer era In fact, that's something we use a lot in the app, using key to constrain the ratio when resizing objects. That's resizing homothetically! -
Hardcopy output
Wosven replied to William Overington's topic in Pre-V2 Archive of Desktop Questions (macOS and Windows)
I usually use a minimum of 118 pixel for 1 cm (10 mm), when checking images for print in magazines (or 120 pixels/cm, simpler to multiply). You could need a better resolution if there's text, since it need more details or it'll look blury. 300 PPI is a minimum (but we accept 280 if the image is good... or we can use more). If you work with vectors, you can use an omothetic size, and export at the one you want later, in the export panel or using the export persona (AD & AP). -
They work directly on the server, that's why it's important one of them, the second to open the file, get a warning. Adobe suite will lock the file and prevent you to open it. Adobe reader will prevent you to erase or move it. Office suite will warn you and allow you to open it on read-only mode. You'll be able to unlock it, and modify it. I never tested modifying and overwritten coworkers modifications, since it would be silly to do so, so I don't know if there's further warning before saving. In the case copies are made on computets, instead of working on the server, I asked people to use "versioning" (adding "_v1, _v2..." suffixes), since it's a pain doing extra hours preparing a file for someone and having your file erased by an older version... because this person did a local copy, needing to do it again. Each workflow need its set of rules, they don't need to be complicated, just to avoid extra/double work. You can work from home on a distant server from your work laptop like I do today, or better, like I did in the past years, connecting your own computer — or a smaller one or laptop provided — to your big and powerful tower at the office (less lag this way with the professional Internet connexion used by the working machine, your personnal connexion only needed for the remote access app data, for viewing).
-
Hardcopy output
Wosven replied to William Overington's topic in Pre-V2 Archive of Desktop Questions (macOS and Windows)
Merci William, c’est tout de suite plus parlant et plus gai ! -
What I can imagine is this: an APub file, and the copy-editor and the graphic designer wanting to work on it at the same time. One of them will wait for the file to be available to work. But usually they work in team, so talking/messages will solve the problem (which one begins/what's more urgent). 2 people wanting to work on the same image/design... Again, the file should be locked, and discussion should help take a decision. Or a shedule. There's 2 problems here: filr need to be locked, people need to talk when coworking on the same files.
-
Hardcopy output
Wosven replied to William Overington's topic in Pre-V2 Archive of Desktop Questions (macOS and Windows)
Hi @William Overington Those are long posts... perhaps adding images instead of links or PDF would help get more answers. If someone had a problem in front of me, after asking for a doctor or trying to call help, I/help would search in a wallet or handbag for card with health datas, not a keyring (unless the person is conscious enough to show the keyring). But I suspect any medical staff will check or be more at ease with official information/card that the ones provided by a keyring. -
Ordinals (a new edition) (2018, 4th edition)
Wosven replied to dvdrw's topic in V1 Bugs found on macOS
It seems like a bbug, since as you said they aren't dependent of language option or at a final position or following a digit/number, or roman numbers ( primero: 1°, secundo: 2°, tercero: 3°…). I hope one day we'll be able to use regular expressions in paragraph styles for such things, since it can be tricky: 1er, 1ers, 1re, 1res, 2nd... 3e, 3es... but also XIe (siècle), IIIe, etc. And a word like "vie" (life), or with similar ending can be finish in superscripts by error if badly implemented. I suppose each language get similar problems with automated superscripts. But being able to code/use regular expressions to add superscripts is time saver, I would have a hard time living without. -
@R C-R There are some point we'll nevers agree upon. I don't think you ever woek in a studio where you already have a tight shedule, and new jobs are added and you should do them anyway between magazines and ads, books. Or send them to coworkers or external help. You can't spend enough time -- or what you would think sufficient to do a better job --, and anything that can be a problem, or a waste of time should be avoid. Since you have coworkers or send file to others indies, you need to avoid everything that's not straithforward and be cause of confusion. I was able to keep on using AP at work after the tests, and I used it because it was faster than the last versions of PS (taking an awfull long time for opening each file), but I also waste time with AP 's bugs, or bad implementations, etc. There'a lot of little improvments asked on those forum, that would smooth and improve worflows. But years go and the list grow. You can keep on finding excuses or try arguing other users demands, but this doesn't help improve the apps.
-
I've got a similar table of all symbols used in ID, and that's sort of my bible, always following we, in a stack of paper near each PC. It's used to reconize symbols you barely use but need to understand why it's in the document you're working on, to help write regular expressions without extra-clicks like you write in your own language, writing scripts in which you can't use the app's own symbols but need unicode values, etc. It goes with some post-its with alt+xxxx most usefull -- but not so frequently typed -- characters unavailable on the keyboard, or table with Zapf Dingbats / Wingdings / etc. symbols/characters you don't want to spend more than few second searching in a glyphs panel... It is certainly important in an app unable yet to memorize search & replace queries. And another important point is it can help learn to use some of those characters you don't even know (or read about long ago), or just help retrieving the relevant one you forget (this one you're searching, you know you read about it somewhere... supposed to do this or that and that you need right now!).
-
No, it's having the same extension to open a book with lot of pages in AD/AP that's confusing, or the same with the 2 other file types that are usually different type of projects you don't want to open in the "bad" app. [edit] Extensions are the logical and perfect solution, avoiding the need to add more suffixes. Complexe nomenclatures for files is enough in a company without needing to add suffixes for apps because it was poorly implemented. When working on servers with lot of folders organized, you tend to avoid lenghtening files' names. [/EDIT]