Jump to content
You must now use your email address to sign in [click for more info] ×

Wosven

Members
  • Posts

    4,129
  • Joined

  • Last visited

Posts posted by Wosven

  1. Bonjour @Piou,

    En fait, la commande fusionne tous les calques visibles en un seul au dessus du calque sélectionné (qui peut être parmi tous les autres).

    Donc il est logique que l'on puisse encore sélectionner les calques non fusionnés.

    Quelle serait la suggestion ?

    ======

    In fact, this command merge all visible layers in one above the selected layer (and this one can be among the others).

    So, it's logical to be able to select the layers that aren't merged.

    What is the suggestion?

  2. 1 hour ago, R C-R said:

    My question is how could APub export that document to the IDML format & preserve that property?

    Sometimes, ID's files can be corrupted and bugged... the first reflex is to save as... and if it's not enough, we try export to IDML. This can take longer depending of the file. It's also possible opening the file or IDML with another ID version will correct the problem.

    I didn't looked at the resulting IDML, but it's possible it's checking and deleting any data or propertie unused by the document, or causing trouble, as a repair mode.

  3. 1 hour ago, Liak said:

    Why would that be the case? Affinity would open the same folder every time you import, because usually, the stuff to import is collected in one place.

    No.

    For example, you can have servers with folders like this:

    server/type of work (= booklet, books, magazines, etc.)/template by document (= a lot of folders)
    server/usefull/type (logo, recurrent pictures, documents, etc.)

    server for archives/year/client/type of work/specific document
    server for archives/year/type of work/specific document #n issue

     

    So you can have multiple pathes you use daily on different servers to get templates or usefull items, the folder in which you work on your computer, the server on which you archives or work/share files or export...
    And you'll have your own set of folders (local or shared) when working on files, until it's complete and you can exporty/archive them.

     

    That's why we ask the apps to memorise some paths globally (export, archive…), or by document's folder (open/import/save/save as...).
    Because when working on different documents in the same day, sometimes opening them simply to do minor corrections, or importing a new picture and exporting a new PDF, and closing the file... it's a pain to search where you exported this last PDF since the app use the previous document's path.

  4. 7 minutes ago, LondonSquirrel said:

    when the non-Adobe app encounters an Adobe-only feature? How does your app handle that?

    Like anyone that dont have a dictionary available: you ignore it or you bug, if there's dependencies...

    But it's the same with Affinity apps-only features: they won't be exported, perhaps it'll be rasterised if it involve adjustments, etc.

  5. With an linked document, you can modify it annualy or punctually, it's like for logo: each time you open a document with this file imported, and it has been modified, you just need to update the link.

    You can have hundred of files using this linked file.

    Or you can have hundred of ads linked to a server with all the logos organized. A company have a new logo? Just modify the logo on the server, and check, if it's used in a file, that it's updated and get enough space on the document.

     

    If we had a way to have "colour profile blind" documents, keeping the exact values set for CMYK or Pantone or other predefined colours swatches, we could import those documents in other ones and export depending of the needed spec. And the convertion would only occur when exporting to PDF, like other apps do.

    For example, we use different types of paper for cover or inside paper in magazines, books or newspaper. Each time, I need to export or ask people to send me correctly exported ads with the appropriate profile. If I try to convert an already converted file, it'll be a mess, and the colours will be wrong. That's why it's important to begin with files with correct colours.

  6.   

      

    12 hours ago, Leaving-Adobe said:

    Do Affinity's programmers / deciders really think that Adobe would alter its .idml-specs as soon as Publisher is able to export into it? And even if they did: Isn't the hassle to adapt to eventual changes in .idml worth it - comparing to the trouble we professionals have NOT BEING ABLE AT ALL to share our work with the rest of the world who still mayorily uses Indesign? Isn't that ignoring facts? To let us Publisher fans force or at least convince service providers or collegues to "also buy, install and learn" Affinity isn't nice. To say "Well then you're better off staying with Adobe"s subscription trap hell, neither.

    To be honest: I just realice Affinity Publisher is a dead end road concerning colaboation – i would have never though that and it annoys and saddens me.

    You've got previous answer in this thread:

    Now, about the collaboration part, if you only do simple files, like simple ads, without any special links, etc. No problem, it's possible to collaborate with someone working with APub.

    But for important work, like books and magazines using advanced features not yet — and probably never — in APub, it would be a complete mess to send back a file made with another app than ID.
    And certainly the end of a collaboration if people need to spend hours correcting your files to get back to a proper ID file. 

     

    IDML is simply an archive (zip) containing XML files. The same as DOCX, XLSX...
    XML is fabulous for structuring datas. But ID exists for long, and there's a lot of data, and I'm not sure  Affinity's goal is to produce apps and files reproducing such structure (this documentation, helpful for scripting, can give an idea):
    https://www.indesignjs.de/extendscriptAPI/indesign16/#about.html

     

    2 hours ago, MikeW said:

    Concerning Adobe changing .idml, it's possible, of course. But it would also break compatibility with past versions of ID. It would only be viable for then then current and future versions. They have too many users that need to use past versions to do that change, I think. 

    IDML is modified as some point, cf. different versions of the InDesign ExtendScript API linked above. Some variables can be renamed, or added, etc.

    Adobe don't mind people switching to the last version of ID, they don't want people using old versions. For now, it's only people writting scripts that shoud manage the difference between version. New datas are ignored when parsed by older versions of ID, and set to default.

    For example, between CS4 and CS5, they added individual values for round corners. If parsed by older versions, all the corner are square. If you need to maintain the visual effect, you'll have to use tricks.

    2 hours ago, MikeW said:

    Because if Adobe changed the format without the present ability to degrade features...the thing that makes CS4 through last year's CC to open .idml...there would be mass migration to other applications. 

    In the last year, I never saw a file made with ID version prior to 2014-2015 (and we were among the few that were using CC2014, instead of the last version). But I'm not a printer, and people here seem to use old versions. At some point, when everyone will need to upgrade the hardware, they'll have to do the same with the apps.

     

    3 hours ago, Leaving-Adobe said:

    Wouldn't altering IDML piss off a lot of Indesign users, too? What does altering mean concerning re-adaption. Is this really a point?

    I'm not sure what you mean by this.

    But if APub export to IDML, it should be usable files, without alterations, or it'll be bugged.

    At some point, a file going from ID > APub > ID > APub ... will be a total mess or unusable, or so simple — stripped of different values only used by the other app —,  that it'll be better to redo a complete document in the appropriate app to use interesting and advanced features, than using a file reduce to simple and non manageable items (variables reduce to simple text, GREP converted to overrides, decorations not sticking to their paragraphes but reduces to curves, etc.).

     

    3 hours ago, walt.farrell said:

    XML is a file format.

    You would need some kind of document-level specification (e.g., an XSD), ideally standardized but with capabilities for extension.

    3 hours ago, walt.farrell said:

    At this point, IDML can be used as an interchange format (though it should not be).

    XML is a language, to share data.

    Microsoft and Adobe did a good job structuring their datas using XML, so now, other apps can read the files and convert them in their own structured datas.
    If it would be a good idea to develop their apps with this in mind, so their code can be easily translated to IDML, or IDML converted to their own code, I'm not sure it's the way Affinity apps are done.

    And working independently, give them more freedom, to search new ways to do things. But it can also lead to bugs, like we saw in another thread about SVG. If the apps are too different, and work in a completely different way it's difficult to output code created with other ideas in mind.

     

    11 minutes ago, walt.farrell said:

    Yes, but perhaps "feature-complete" was the more important part of that statement.

    How do you import or export features not yet implemented in a file format?

  7. And an adjustment would rasterize the content, not really what we want for text.

     

    The not optimal but "best" way to do this would be, and if you only use PDF 1.4 to 1.7:

    • to use an application palette in the footer document,
    • and export this footer as PDF.
    • to import the PDF in other documents,
    • And use "assign" when needing a different profile in a document in which the PDF is placed.

    2022-02-13_153431.png.03463d69f6a7cdedde304482ef71c1a4.png

     

    But it would be better if the apps were working differently with colour values and profiles.

  8. The problem is more complexe, since it's also the way the clipping path work, it's different:

    2022-02-12_205919.png.6925c335587ac7bd611329536baf131f.png

    2022-02-12_210642.png.9e4e414419d0d6fd7e09e9e9ce44213b.png

    2022-02-12_213355.png.9733f4923812f3ae3a22e49020b72e64.png

    2022-02-12_212257.png.34c32c6a3306760a9feb80143cffbe57.png

     

    The file corrected (17Ko):

    g62030967718039a3974574f67a8eb81a88f7b78584425d691fc477129b8de_AD.svg

    If you look at the code, Affinity apps are able to use this effect, but they do it in a messier way...

    Original file (5Ko):

    g62030967718039a3974574f67a8eb81a88f7b78584425d691fc477129b8de6651dc6a022b17b213fa3c469365e900050.svg

  9. 15 minutes ago, Alfred said:

    And that’s exactly what we have. Speech recognition for a limited set of words

    Possibly, but we don't like it in France, and it didn't take. We nearly went from employees at the wickets to vending machines or web sites.

    I can remember an unpleasant moment, when trying to buy a train ticket from a remote location without Internet, and needing to do it on the phone. After few failed attempted calling this overpriced service, and giving the wrong answer in the last umpteenth questions, I ended up writing down the whole sequence of numbers, to avoid error and finalize successfully the call.

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.