Hi Greg, Sorry! Only now I see that I top-posted! Looks like I just scribbled away the message in too much a hurry! Sorry guys!
Gregory Pittman wrote: > I think you may be right about this, but it seems this is more of a > >"best practices" kind of advice, that might do well to be on the Wiki so >others can avoid subsequent frustration. > > It was Christoph's idea so he is the right person to do it. (Besides, I have forgotten everything about how to put stuff on Wiki! :) >>Perhaps, out of workflow optimization issues, >>images could be put on a separate hard-disk in a separate content >>managemnt server (the image directory being linked/mounted on the local >>disk) so that the graphic artists as well as the DTP experts could work >>in parallel. >> >> >For some, this may be the preferred way of working -- having a static, >well-organized image directory with subdirectories, and in that case, >they might not want the bother of making copies elsewhere. > > > >> When everything has been finalized (images are approved, >>text has been proofread, layout is approved, etc.) and those files are >>needed together in one directory - perhaps Scribus could use some kind >>of an export/collect functionality. >> >> >One thing which has occurred to me is that, even though some of the >Scribus team seem to wince at the thought, the fact that .sla files are >text-based means that, even if one commits a "faux pas" such as David >did, it is possible to load the .sla file into a text editor and do a >search-and-replace operation to fix all the image references in the .sla >file. > > Yes! :) Text files can easily be changed. Actually, because of skimming through this thread and the kind of work I am currently engaged in, it occurred to me that a DTP workflow could be organized using a content management system that made good use of the "Strategy Pattern" which means that developers could use a generic strategy for the base content management system and domain-specific strategies for .sla's and DTP related work, for example - that is, the child strategies derived from the generic top-level base strategy (genuinely super-functional polymorphism in play!). That way, additional strategies could be derived from the generic one so that the same content management system could manage additional types of content - for example, web design, SVG, etc. Since different domains (DTP, web development, etc.) have different disk-IO requirements, the content management system could employ different storage/data management engines/technologies to take care of each. Since managing different types of content on the same disk/system could be a potential bottleneck due to disk-IO requirements of each, different types of content could be stored in different data/cms repositories residing on different systems - all repos being controlled by the main cms in a location-independent device-independent manner - I am thinking about Jini when I am writing this (because of the location/device independent stuff). Storing each type of content (SVG/EPS, SLAs, Web pages, etc.) on different machines would enable domain-specific experts (vector graphic artists, dtp experts, for example) to work efficiently on their stuff. The domain-specific content would be managed by the domain-specific strategy pattern derived from the generic strategy pattern of the main content management system. There would be no deficit in performance in managing the content since storage/data repository management code (domain-specific strategies, that is) for each type of content would be specifically written to manage that specific type of content. This is important because using CVS for code is different from using the same for SLAs - each has different IO/performance requirements. Talking about the jar file, IIRC, the jar uses the same zlib that Scribus indirectly uses (JPG lib, PNG lib or another dependent lib uses it). If the developers do plunge into developing a content management system like the one I mentioned above ;) then a mechanism similar to JAR (1- importing/collecting images from different data repos and zipping it into one file so that it can be moved/unpacked elsewhere so that a user could work on the content locally) could be employed for the sole purpose of keeping _everything_ into _one_ file. When I am talking about this all, I am also wondering about the possibility of managing the bitmap content by storing time-stamped history of actions as well as structure (layers, selections, paths, channels, etc.) _externally_ . Perhaps this (and prior) post of mine doesn't belong here in this thread. I would certainly like to hear from the developers. What do you think? These are just my views. -- Best regards, Asif
